On Thu, Mar 28, 2019 at 4:55 PM Lendacky, Thomas <Thomas.Lendacky@xxxxxxx> wrote: > > On 3/28/19 2:57 PM, Nathaniel McCallum wrote: > > 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 > > I'm just going to address the SEV-ES/ LAUNCH_UPDATE_VMSA portion of this. > And, just to be clear, there has been no SEV-ES support submitted yet, so > the KVM_SEV_LAUNCH_UPDATE_VMSA doesn't exist yet. https://github.com/torvalds/linux/blob/master/include/uapi/linux/kvm.h#L1451 The kernel already exports a definition for it. > > 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. > > Given #2 below, these calls aren't needed. > > > > > 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. > > Since *ALL* vCPUs have to be measured for an SEV-ES guest, the kernel / > hypervisor would just call LAUNCH_UPDATE_VMSA for every vCPU in vCPU# > order when required (this is not done for an SEV guest). There would be > no need to even have a KVM_SEV_LAUNCH_UPDATE_VMSA. Are you implying that when SEV-ES support lands the kernel will implicitly call LAUNCH_UPDATE_VMSA during the hypervisor's KVM_SEV_LAUNCH_MEASURE call? If so, the aforementioned definition for KVM_SEV_LAUNCH_UPDATE_VMSA should be removed. I support the removal of KVM_SEV_LAUNCH_UPDATE_VMSA from userspace altogether. I don't want the hypervisor to have to think about the ordering. The kernel just needs to get it right. That still leaves us with KVM_SEV_LAUNCH_UPDATE_DATA batching.
