>-----Original Message----- >From: Daniel P. Berrangé <berra...@redhat.com> >Subject: Re: [PATCH rfcv4 08/13] Add Intel TDX Quote Generation Service(QGS) >support > >On Wed, Mar 26, 2025 at 03:29:04AM +0000, Duan, Zhenzhong wrote: >> >> >> >-----Original Message----- >> >From: Daniel P. Berrangé <berra...@redhat.com> >> >Subject: Re: [PATCH rfcv4 08/13] Add Intel TDX Quote Generation Service(QGS) >> >support >> > >> >On Fri, May 24, 2024 at 02:21:23PM +0800, Zhenzhong Duan wrote: >> >> Add element "quoteGenerationService" to tdx launch security type. >> >> Currently it contains only one sub-element "SocketAddress". >> >> >> >> "SocketAddress" is modelized according to QEMU QAPI, supporting >> >> inet, unix, vsock and fd type and variant attributes depending >> >> on type. > >> > >> >The 'fd' socket type does not make sense to expose >> >in libvirt XML. FD passing is something handled >> >privately between libvirt & QEMU, not a end user >> >choice. >> >> Yes, I can remove ' FdSocketAddress fd'. >> >> > >> >Going further I don't think InetSocketAddress >> >makes sense to expose, as QGS has no ability >> >to listen on IP sockets. It can only do UNIX >> >sockets or VSock AFAICT. >> >> Why can't qemu connect to QGS on a remote hoste? > >QGS has no IP support, and the work that QGS >performs to create a signed attestation report >has to be done on the same host that the VM >runs on. > >> Even if connect to QGS on localhost, 127.0.0.1 can be used. > >Again QGS has no IP support, and 127.0.0.1 offers >no benefits over UNIX sockets, while having worse >security.
Clear. > >> > Even vsock looks like >> >a remnant of the old way of doing attestation >> >before it was integrated into Linux via sysfs >> >with the kernel making a call into QEMU. >> >> Not get, qemu does support vsock, see https://lore.kernel.org/qemu- >devel/20240229063726.610065-50-xiaoyao...@intel.com/ > >That's simply an artifact of the QEMU patches using QEMU's >generic socket APIs. The QGS vsock support dates from the >earlier days of TDX development, where the guest VM would >be directly connecting to QGS. With QEMU & the kernel >mediating access to QGS, enabling VSOCK is not required. >VSOCK decreases security of the host - it allows any >running guest (whether confidential or not) to directly >attack QGS via any of its protocol messages. With QEMU >mediating QGS access, the malicious guest would need to >compromise the kernel, and QEMU before it can access >QGS. Understood. > >I'm not seeing a compelling functional reason to enable >QEMU to connect to QGS over VSOCK in libvirt, when UNIX >sockets offer the required functionality with greater OK. >security. > >> >IOW, AFAICT, for QGS all we actually need is >> >the ability to set a UNIX socket path in libvirt. >> >eg >> > >> > <quoteGenerationService path="/var/run/tdx-qgs/qgs.socket"/> >> >> Hmm, then we go back to opaque string, do you change your mind? >> See >https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/XCE4F4FCRFI >P7IVZCFPB6RDWLEWXXT2G/ > >The original patch was an opaque string, because it was encoding >various different socket address types in one string. > >What I'm proposing is different. Do NOT support different socket >address types initially, only support UNIX sockets, and the only >attribute is thus the bare UNIX socket path. > >If we start with only supporting: > > <quoteGenerationService path="/var/run/tdx-qgs/qgs.socket"/> > >then in the unlikely even we need more socket types we can extend >this, by adding a "type" attribute defaulting to "unix" if omitted, >so we can then allow a choice > > <quoteGenerationService type="unix" path="/var/run/tdx-qgs/qgs.socket"/> > >or > > <quoteGenerationService type="vsock" cid="...." port="..."/> > >but hopefully we'll never need this, as UNIX sockets should suffice. Sounds good, will do this way. > >> >and probably libvirt should allow 'path' to be optional >> >so an app can just do >> > >> > <quoteGenerationService/> >> > >> >and libvirt would fill in the default path which QGS listens >> >on out of the box.... >> >> Yes if we have such default QGS path, do we? > >Yes, it is hardcoded in QGS source code: > >$ git grep '#define QGS_UNIX_SOCKET_FILE' >server_main.cpp:#define QGS_UNIX_SOCKET_FILE "/var/run/tdx-qgs/qgs.socket" OK, will do. Thanks Zhenzhong
