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. > > How difficult would it be to put up a prototype that uses only IGVM as > vmfwupdate payload? We can definitely assemble that IGVM in ukify.py or > as part of the boot stub. Or for the prototype even pre-assemble by hand. > > > Alex >
