On Thu, Mar 13, 2025 at 4:29 PM Jörg Rödel <j...@8bytes.org> wrote: > > Hi Ani, > > Don't get me wrong, I really like the general idea of vmfwupdate as > a way to implement BYOFW, and for non-confidential VMs it is great. I > just think the interface design is not well suited for confidential VMs > yet and want to discuss how to change that. > > On Thu, Mar 13, 2025 at 04:02:11PM +0530, Ani Sinha wrote: > > Forgive my ignorance, today none of the hyperscalers use IGVM to > > define this. How then the expected launch measurement is derived? > > There is at least one Hyperscaler which uses IGVM, another implemented > support for it in their hypervisor (although not for a BYOFW feature, > yet). In my view this problem is still widely being worked on today by > the CSPs. If you are lucky, and since the firmware is provided by the > CSP as well, they publish expected launch measurments for each of their > coco platforms. > > > Our vmfwupdate interface does not make any attempt to define this in > > any way or make this an ABI. Its intentionally open ended. It's really > > up to the guest to set this up any way they wish. This is the same > > when the guest provides the igvm file that defines the above. > > Without a way to supply user-defined setup steps of a confidential VM > the host-VMM has to hardcode them. And that hardcoded behavior becomes > ABI implicitly, because any change to this behavior will also change the > actual launch measurements, potentially breaking existing users.
Right so what we are proposing is generic enough so that if the VM wants to use an IGVM container as opposed to an actual firmware image in a FUKI, that is totally possible. Then you need to have that IGVM setup the memory in a well defined way like you suggest. Sure, the IGVM is not passed through a command line but it can be loaded by the guest in a well defined memory location and then its instructions can be executed. In our proposal, we do not want to dictate how the guest would want to do that. So hopefully you see now that IGVM and our approach is not mutually exclusive but can be complementary to each other. > > This happened in the past already when KVM decided to hardcode a > different set of SEV-Features by enabling Debug-Swap. I strongly believe > that with KVM/QEMU we should work in a direction which makes those > breakages unlikely in the future. > > Regards, > > Joerg >
