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

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

On Fri, Mar 21, 2025 at 11:08:11AM +0100, Gerd Hoffman wrote:
>   Hi,
> 
> > >      While digging around in the igvm spec I've seen there is the
> > >      concept of 'parameters'.  Can this be used to pass on the memory
> > >      location of kernel + initrd + cmdline?  Maybe the kernel hashes too?
> > 
> > The find the locations of the kernel, initrd, cmdline, ... I think IGVM
> > parameters, either directly or (preferably indirectly) are a good
> > solution. By "indirectly" I mean to put these regions on a separate and
> > measured page which also contains the region hashes.
> 
> regions and hashes should be separate I think.  The regions are not
> necessarily fixed, the physical memory location where things have been
> loaded to can change.
> 
> But also see my other reply.  I'm not convinced any more carrying
> forward the hashes logic makes much sense.
> 
> > >  (2) Will the igvm be generated on the fly from FUKI data?  Or should
> > >      the distros ship igvm images with firmware + kernel + initrd?
> > 
> > My preference would be that distros ship the tooling and components to
> > build IGVM files and build them during kernel update. If a distro comes
> > up with a generic initrd+cmdline it can also ship pre-built IGVM files.
> 
> Working with the (F)UKI instead has the advantage that we can make use
> of the secure boot signature, with a workflow along these lines:
> 
> (distro) build:
>  * Embed the firmware as igvm inside the UKI.
>  * Sign the UKI.
> 
> first vm launch:
>  * Load the complete UKI.
>  * Pass on (a) the igvm section and (b) the UKI (including signature)
>    to the vmfwupdate device.
> 
> vmwupdate device:
>  * loads the igvm image.
>  * passes on the UKI location (as igvm parameter?).
> 
> second vm launch:
>  * firmware checks UKI signature.
>  * firmware (optionally) measures UKI into vTPM.
>  * firmware launches UKI.

> 
> Going ship the distro kernel as igvm image would work too.  Will
> simplify the measurement pre-calculation.  Also there is no need to pass
> around any parameters, everything (how the firmware finds the UKI etc)
> can be arranged at igvm build time then.  Disadvantage: This introduces
> a completely new boot workflow.  Will probably need a new set of cloud
> images exclusively for the BYOF case.

Having a completely different boot workflow & images for CVM BYOF that
does not involve/consume existing UKIs & addons feels pretty undesirable
to me.

If the baseline is that the distro/user is using UKIs for everything,
and then they want to do BYOF, that change should involve as little
difference as possible to pull firmware into the mix. Your first
workflow example with FUKI looks like it would satisfy that, but
switching to bundle the kernel/initrd/cmdline directly in the IGVM
would not.

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