On Fri, 21 Mar, 2025, 3:38 pm Gerd Hoffman, <kra...@redhat.com> 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. > What does all this mean for the hypervisor interface ? >
