On Wed, Mar 26, 2025 at 03:29:04AM +0000, Duan, Zhenzhong wrote:
>-----Original Message-----
>From: Daniel P. Berrangé <berrange(a)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.li@in...
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/X...
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 :|