* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Thu, Feb 10, 2022 at 07:39:01PM +0000, Dr. David Alan Gilbert wrote: > > * Daniel P. Berrangé (berra...@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 / dgilb...@redhat.com / Manchester, UK
