Hi Jörg,
On 13.03.25 16:39, Jörg Rödel wrote:
On Thu, Mar 13, 2025 at 08:23:44PM +0530, Ani Sinha wrote:
Note that even with this approach where the hypervisor *thinks* it's
dealing with a real firmware, you can imagine a small rust based
firmware image that is loaded by the guest in the firmware region.
This tiny firmware then jumps to a well known address (chosen by the
guest) where IGVM is loaded and then starts executing the IGVM
instructions.
Yes, but this way the predictable launch measurement property of IGVM
is lost, as the measurement only contains hashes for the actions
which happened before the VM was finalized and launched by the VMM. The
SEV policy can also not be changed anymore when the guest is running.
Anyway, I think it doesn't matter much whether the IGVM is parsed in
guest context or by QEMU, as long as the resulting measurement is the
same as if the file was loaded at initial VM launch.
Given that QEMU will hopefully get IGVM backend support soon, there is
some value and saved effort in just passing the IGVM data to the VMM via
the vmfwupdate interface and let QEMU do the rest.
I have a few concerns with IGVM:
1) Parsing is non-trivial. Parsing them in QEMU may open security issues.
2) Their data structures are tied to the target CPU structures like VMSA
which FWIW are not fully owned by QEMU, are they?
3) I don't want to allocate a bounce buffer for an IGVM in the
hypervisor. So we would need to ensure that the memory allocated by the
loader for the IGVM does not overlap any memory the IGVM wants to
consume. If the loader considers the IGVM as opaque, that is difficult
to achieve.
Alex
