Re: [PATCH] qapi, i386/sev: Add debug-launch-digest to launch-measure response

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Feb 10, 2022 at 07:39:01PM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > I wonder if we're thinking of this at the wrong level though. Does
> > it actually need to be QEMU providing this info to the guest owner ?
> > 
> > Guest owners aren't going to be interacting with QEMU / QMP directly,
> > nor are they likely to be interacting with libvirt directly. Their
> > way into the public cloud will be via some high level API. eg the
> > OpenStack Nova REST API, or the IBM Cloud API (whatever that may
> > be). This high level mgmt infra is likely what is deciding which
> > of the 'N' possible OVMF builds to pick for a given VM launch. It
> > could easily just expose the full OVMF data to the user via its
> > own API regardless of what query-sev does.
> > 
> > Similarly if the cloud is choosing which kernel, out of N possible
> > kernels to boot with, they could expose the raw kernel data somewhere
> > in their API - we don't neccessarily need to expose that from QEMU.
> 
> It gets more interesting where it's the guest which picks the
> kernel/initrd; imagine the setup where the cloud reads the kernel/initrd
> from the guest disk and passes that to qemu; one of the update ideas
> would be just to let the guest update from a repo at it's own pace;
> so the attestor doesn't know whether to expect a new or old kernel
> from the guest; but it does know it should be one of the approved
> set of kernels.

So that scenario would effectively be the old Xen style pygrub where
you have some script on the host to pull the kernel/initrd out of
the guest /boot.

On the plus side that would enable you to use a "normal" guest disk
image with unencrypted /boot, instead of encrypting everything.

The risk though is that you need a strong guarantee that the *only* data
from /boot that is used is the kernel+initrd+cmdline that get included
in the measurement. If the guest boot process reads anything else from
/boot then your confidentiality is potentially doomed. This feels like
quite a risky setup, as I don't know how you'd achieve the high level of
confidence that stuff in /boot isn't going to cause danger to the guest
during boot, or after boot.

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 :|