(Excuse my delayed reply, still suffering from some flu or whatever...)
On Mon, Mar 17, 2025 at 10:56:04AM +0100, Gerd Hoffman wrote:
> Yep. But we have to sort the details.
>
> (1) How we are going to load kernel + initrd in case the firmware is
> igvm? Just update the igvm to also include linux kernel and
> initrd (see parallel reply from Jörg)? If so, how does the
> launched firmware find the kernel + initrd?
> 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.
This allows to put these regions as unmeasured memory into the IGVM and
speed up launching on some platforms.
> (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.
>From that IGVM-file the tooling can also extract expected measurements
and place them on some trusted verifier (e.g. remote or TPM).
> (3) How we are going to handle uki add-ons?
>
> (4) Do we want keep the region list? Or declare that igvm should be
> used in case a single region is not enough? Or even go all-in and
> use IGVM exclusively?
No strong opinion here, but I just want to mention again that by
allowing a workflow with a pre-defined setup order for CVMs, the
implemented order in QEMU/KVM can not be changed afterwards without
breaking measurements for users.
Regards,
Joerg
