During the launch of an SEV-enabled guest, a measurement is taken of all plaintext pages (KVM_SEV_LAUNCH_UPDATE_DATA) and, in SEV-ES, VCPU state (KVM_SEV_LAUNCH_UPDATE_VMSA) injected into the guest. This measurement becomes part of the chain of trust reported to the guest owner. Currently, the kernel passes these commands somewhat directly to the firmware for measurement. Likewise, the firmware calculates the measurement of the data in the order it is received. This is fragile. It means that the entire burden for reproducing the measurement falls on the hypervisor. In turn this means that slight, even unintentional, changes of the ordering by the hypervisor can result in different measurements on different hypervisor versions. There is also a secondary problem that, even though it controls CPU state, the KVM_SEV_LAUNCH_UPDATE_VMSA is called on the KVM virtual machine file descriptor. In order to support multiple vCPUs, you have to call it once for each vCPU - in the order the vCPUs are assigned to the guest. Hypervisors typically call this vCPU initialization code in an independent thread, making this ordering somewhat cumbersome (QEMU does this today). In response to these problems, I'd like to propose the following: 1. Calls to KVM_SEV_LAUNCH_UPDATE_VMSA are moved from the VM fd to the vCPU fd. 2. All calls to KVM_SEV_LAUNCH_UPDATE_DATA and KVM_SEV_LAUNCH_UPDATE_VMSA are batched by the kernel. When KVM_SEV_LAUNCH_MEASURE is called, the kernel forwards all batched calls in a well defined order to the firmware. First, it would send all LAUNCH_UPDATE_DATA commands (in guest address order?). Second, it would send all LAUNCH_UPDATE_VMSA commands in vCPU # order. This ensures that, so long as the contents of the VM are the same, the measurement is the same across all hypervisors and hypervisor versions.
