On 5/6/21 8:32 AM, Daniel P. Berrangé wrote:
On Thu, May 06, 2021 at 08:04:44AM -0500, Connor Kuehl wrote:
> On 5/6/21 6:51 AM, Daniel P. Berrangé wrote:
>>> It looks like QEMU will expose commands needed for attestation via QMP [3].
>>
>> As mentioned in my reply to that thread, I believe we can already do
>> pretty much all of that via a combination of libvirt APIs & guest XML.
>
> This is not a good user experience. The entire attestation process
> should be made ephemeral, taking place 100% over a socket. Enabling a
> fully socket-based attestation workflow will decouple it from the domain
> XML and the host file system and make it easier for guest-owner tooling
> to facilitate attestation.
The libvirt library is also just a client talking to a socket, so
concept that's no different, just using a protocol libvirt has defined
at a higher level instead of a low level hypervisor specific protocol.
The tools that are managing the VM lifecycle are already using libvirt
as their API, and already doing several of the steps described wrt to
SEV. It is not realistic to expect them to take a completely different
approach to managing the startup of VMs that have SEV enabled, they
need to have a way to integrate with their existing approach to mgmt.
The guest owner has to in turn talk to some mechanism that the
management app exposes to them. These management apps are pretty
unlikely to wish to directly expose a low level impl detail of QEMU.
They won't even expose the fact that they're using libvirt in fact,
instead presenting some higher level API again, as they rarely wish
to leak low level hypervisor details outside as that locks them into
supporting specific low level details long term.
I see. So it sounds like the way forward for libvirt is that it will
need to essentially duplicate the SEV-related QMP message types into its
own protocol since expecting the client to understand QMP discloses the
fact that the underlying hypervisor is QEMU.
Connor