On 14.03.25 12:27, Gerd Hoffman wrote:
Hi,
Open question is what we do about IGVM.
One option would be the guest vmfwupdate tool loading and parsing igvm,
preparing the region list, then invoke the update. Problem is that some
igvm feaures such as initial register state can not be easily supported
that way.
We could also expect the hypervisor support igvm, so the guest can
simply load the file into memory and pass address and size to the
hypervisor. Either as option, say via VMFWUPDATE_REGION_FLAG_IGVM, or
mandatory, i.e. scratch the region list and use IGVM exclusively.
This is of course up to the QEMU maintainers to decide, but I want to
highlight that IGVM already solves all the problems mentioned above,
including setting multiple memory regions of different type, special
data pages (cpuid, secrets, id-blob, vmsa) and more. It defines the
order of setup calls the VMM has to invoke for the new context and also
works for multiple platforms like TDX, SNP, non-coco, and in the future
ARM as well.
My take on this is that instead of making the interface more complex,
let's empower the guest to use IGVM if they think they need more
guarantees around those things that IGVM solves very well today. QEMU
already has IGVM backend support.
Ok, assuming we allow the guest submit a IGVM image (which makes sense
indeed, otherwise we'll probably end up re-inventing IGVM). How will
the kernel hashes be handled then? I assume they will not be part of
the igvm image, but they must be part of the launch measurement ...
The kernel hashes must be embedded in the IGVM image by the time you
invoke vmfwupdate. That means when you generate the FUKI, you take 4
inputs: Generic firmware image, kernel, initramfs, cmdline. Out of
those, you generate and embed an IGVM image that consists of the
firmware image as well as the kernel hash page.
Alex
