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.
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
