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

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> 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.

Right.

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

Yes; the other plus is that you don't need the guest to send update
information back to the attestor to tell it when it's done an update;
that's potentially a big simplification on an untrusted interface.

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

Which I think pygrub type things found out the hard way; but as long as
you copy from /boot, attest on the data you use and then boot using the
data you attested you should be OK.

Dave

> 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 :|
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK