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. > > 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. 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 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/XCE4F4FCRFIP7IVZCFPB6RDWLEWXXT2G/ 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. > >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" With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
