> 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.
v6 patch is outdated, latest approach is to pass a list of regions:
// regions_addr points to an array of this structure
struct vmfwupdate_regions {
uint64_t size;
uint64_t src_addr; // source address (before update)
uint64_t dst_addr; // destination address (after update)
uint64_t flags; // control bits
};
// flags
#define VMFWUPDATE_REGION_FLAG_COPY // data must be copied
#define VMFWUPDATE_REGION_FLAG_ZERO // dest must be cleared
#define VMFWUPDATE_REGION_FLAG_MEASURE // data must be measured
(1) is still not covered.
(2+3) can be handled with FLAG_ZERO regions, with and without
FLAG_MEASURE.
(4) Alex already pointed that the cpuid page is special, guess we
need additional flags for those oages.
Open question is what we do about IGVM.
One option would be the guest vmfwupdate tool loading and parsing igvm,
preparing the region list, then invoke the update. Problem is that some
igvm feaures such as initial register state can not be easily supported
that way.
We could also expect the hypervisor support igvm, so the guest can
simply load the file into memory and pass address and size to the
hypervisor. Either as option, say via VMFWUPDATE_REGION_FLAG_IGVM, or
mandatory, i.e. scratch the region list and use IGVM exclusively.
take care,
Gerd
