On Thu, Mar 13, 2025 at 3:40 PM Jörg Rödel <j...@8bytes.org> wrote: > > Hi Ani, > > On Thu, Mar 13, 2025 at 03:07:42PM +0530, Ani Sinha wrote: > > The state before reset is the state that uses stock firmware from the > > hyperscaler. The state after reset is a fresh new state that uses the > > "trusted and known firmware" from the end user. So the launch > > measurements would not match between the state before reset and the > > state after reset and there is no guarantee that there would be > > "predictable launch measurements" across the reset. > > Right, I understand that the state before and after reset will have > different launch measurements, that is expected when booting with a > different firmware :) > > > What we do guarantee is that after reset, the launch measurements that > > include the "trusted and known firmware" (whatever that is, not > > necessarily edk2), is understood and expected. If you were to > > calculate offline the measurements that include this "trusted and > > known firmware" using the same order of setup calls as the target > > system and then derive the launch digest, it should match that of what > > the hardware would produce in the target. > > The devil lies in "same order of setup calls". Without a way to define > this order through the vmfwupdate interface there is a lot of implicit > knowledge required about how KVM/QEMU setup the TEE context to calculate > the expected after-reset launch measurement. Even worse, the exact way > this setup is done then becomes ABI, because any change in this process > will lead to a different launch measurement.
Forgive my ignorance, today none of the hyperscalers use IGVM to define this. How then the expected launch measurement is derived? 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. > > Some examples of initial memory layout calls which influence the launch > measurment: > > 1) Launch VMSA(s) (SEV-SNP only, though I believe on TDX the > initial register state can also be changed to some > degree). > 2) Pre-Validated/Accepted memory regions (TDX and SEV-SNP). This > is especially important, as different FWs have different > requirements on what memory is pre-validated, zeroed, etc. > 3) Zero-pages, measured and unmeasured (TDX and SEV-SNP). > 4) Position of the CPUID page, secrets page, and id-blob > (SEV-SNP). > 5) Pre-populated data (TDX and SEV-SNP). > > If I understand the vmfwupdate interface correctly, and please let me > know if I am wrong here, it only allows to specify a call for part 5) of > the above list. Some of the other parts can be specified in architecture > dependent ways in the FW image itself, but not all of them. > > So the question is, is the plan to hardcode everything else (including > the order of calls) and make the behavior ABI? > > Regards, > > Joerg >
