[RFC] Allowing SEV attestation

Connor Kuehl ckuehl at redhat.com
Thu May 6 13:43:53 UTC 2021

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.


More information about the libvir-list mailing list