On 21.03.25 04:36, Ani Sinha wrote:
On Thu, Mar 20, 2025 at 7:24 PM Alexander Graf <g...@amazon.com> wrote:
Hey Gerd,
On 18.03.25 12:11, Gerd Hoffman wrote:
Hi,
Maybe not from the user's point of view, but surely for the vmfwupdate
interface design and for the launch measurement calculations.
When using igvm parameters for the kernel hashes we need to pass on (at
least) two items via vmfwupdate API: The igvm image itself and the
kernel hashes, so the VMM can fill the parameters for launch.
I tend to think it makes sense to keep the region list, so we can
actually pass on multiple items if needed, and simply add region flags
to declare that a region is an IGVM image.
Went over the interface spec today, here it is. Changes:
- Moved descriptions into source code comments.
- Added leftovers noticed in recent discussions, such as cpuid page.
- Added capability flags and region flags for IGVM.
Open questions:
- Does the idea to use igvm parameters for the kernel hashes makes
sense? Are parameters part of the launch measurement?
- Do we want actually keep the complete interface (and the functional
overlap with igvm)?
I think if we want to embrace IGVM, we should embrace it fully and make
it replace the region list. At the end of the day, IGVM is effectively a
region list plus data.
Are you suggesting that vmfwupdate only accept IGVM as payload? I am
not sure if I like that idea.
I don't like it either, but I don't see a good alternative. If the spec
allowed both IGVM and the home grown region list, hypervisors would
still need to implement both ways to be compatible with all payloads. So
by adding one more path, we're only adding complexity without helping
anyone.
Alex
