Re: [PATCH v6] hw/misc/vmfwupdate: Introduce hypervisor fw-cfg interface support

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

On Mon, Mar 24, 2025 at 06:53:59PM +0100, Gerd Hoffman wrote:
> On Mon, Mar 24, 2025 at 05:31:30PM +0100, Alexander Graf wrote:
> > 
> > > > > > What does all this mean for the hypervisor interface ?
> 
> > > > > That means we'll go scratch the region list idea and depend on igvm
> > > > > instead.
> 
> > > > > Which means we are back to the single firmware image.
> > > > So in this model, how are we passing the hashes of kernel, initrd and cmdline?
> > > > Are they going to be part of the firmware image as was previously thought?
> 
> > > Either scratch the idea of using hashes to verify kernel + initrd +
> > > cmdline and use a secure boot signed UKI instead, or use IGVM firmware
> > > images and add the kernel hashes page to the igvm.
> 
> > It's a nice idea to have a firmware IGVM file that contains a signature, so
> > you can for example have a RHEL provided IGVM that only runs UKIs that are
> > signed by Red Hat.
> 
> Yep, that is what should be possible when all this is ready.
> 
> >   - Attestable Bootable Containers. In that case, the command line contains
> > a hash of the target fs-verity protected partition. Red Hat can not be the
> > entity signing that UKI. It must be the user.
> 
> Well, add-ons have been created to address exactly that:  Allow the UKI
> being configured without changing it, so the UKI can be signed by redhat.
> You'll go add user-signed add-on for the command line.
> 
> >   - Add-ons. How do you provide a "debug add-on" and prevent it to gain any
> > access to confidential data?
> 
> Not sure I understand the point you are trying to raise.  Add-ons
> signatures are checked too.

"Debug add-on" is quite a broad concept - some things might be safe
for the vendor to ship as pre-built signed add-ons by default, others
things may not be safe & require user opt-in, by signing an add-on
locally with their MOK and enrolling with it shim.

Also UKIs semi-recently gained support for multiple profiles avoiding
the need for addons in some cases[1]. A simple use of this might be two
cmdlines - one quiet by default and one with verbose kernel messages.
A more advanced use would be one "normal" profile, and one "factory reset"
profile

With regards,
Daniel

[1] https://github.com/uapi-group/specifications/blob/main/specs/unified_kernel_image.md#multi-profile-ukis
-- 
|: 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 :|