[RFC] Allowing SEV attestation

Daniel P. Berrangé berrange at redhat.com
Thu May 6 13:51:55 UTC 2021

On Thu, May 06, 2021 at 08:43:53AM -0500, Connor Kuehl wrote:
> 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.

I wouldn't say duplicate the SEV QMP messages, as I wouldn't assume that
there's a direct 1:1 mapping between what libvirt exposes and what QMP
exposes. There will be some mapping, but it could well be M:N, since
libvirt aims to express things as higher level concepts that stand a
better chance of being cross-hypervisor applicable [1], rather than
just 1:1 duplicating QEMU.


[1] In practice we might not achieve hypervisor portability, especially
    if QEMU is the only impl that exists, as we can't reliably predict
    the future of what other hypervisors may do for the same concept.
|: 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 :|

More information about the libvir-list mailing list