On Tue, Dec 14, 2021 at 01:59:10PM +0000, Dov Murik wrote: > Add a section explaining how the Guest Owner should calculate the > expected guest launch measurement for SEV and SEV-ES. > > Also update the name and link to the SEV API Spec document. > > Signed-off-by: Dov Murik <dovmu...@linux.ibm.com> > Suggested-by: Daniel P. Berrangé <berra...@redhat.com> > --- > docs/amd-memory-encryption.txt | 50 +++++++++++++++++++++++++++++++--- > 1 file changed, 46 insertions(+), 4 deletions(-) > > diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt > index ffca382b5f..f97727482f 100644 > --- a/docs/amd-memory-encryption.txt > +++ b/docs/amd-memory-encryption.txt > @@ -43,7 +43,7 @@ The guest policy is passed as plaintext. A hypervisor may > choose to read it, > but should not modify it (any modification of the policy bits will result > in bad measurement). The guest policy is a 4-byte data structure containing > several flags that restricts what can be done on a running SEV guest. > -See KM Spec section 3 and 6.2 for more details. > +See SEV API Spec [1] section 3 and 6.2 for more details. > > The guest policy can be provided via the 'policy' property (see below) > > @@ -88,7 +88,7 @@ expects. > LAUNCH_FINISH finalizes the guest launch and destroys the cryptographic > context. > > -See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the > +See SEV API Spec [1] 'Launching a guest' usage flow (Appendix A) for the > complete flow chart. > > To launch a SEV guest > @@ -113,6 +113,45 @@ a SEV-ES guest: > - Requires in-kernel irqchip - the burden is placed on the hypervisor to > manage booting APs. > > +Calculating expected guest launch measurement > +--------------------------------------------- > +In order to verify the guest launch measurement, The Guest Owner must compute > +it in the exact same way as it is calculated by the AMD-SP. SEV API Spec [1] > +section 6.5.1 describes the AMD-SP operations: > + > + GCTX.LD is finalized, producing the hash digest of all plaintext data > + imported into the guest. > + > + The launch measurement is calculated as: > + > + HMAC(0x04 || API_MAJOR || API_MINOR || BUILD || GCTX.POLICY || GCTX.LD > || MNONCE; GCTX.TIK) > + > + where "||" represents concatenation. > + > +The values of API_MAJOR, API_MINOR, BUILD, and GCTX.POLICY can be obtained > +from the 'query-sev' qmp command. > + > +The value of MNONCE is part of the response of 'query-sev-launch-measure': it > +is the last 16 bytes of the base64-decoded data field (see SEV API Spec [1] > +section 6.5.2 Table 52: LAUNCH_MEASURE Measurement Buffer). > + > +The value of GCTX.LD is SHA256(firmware_blob || kernel_hashes_blob || > vmsas_blob), > +where: > + > +* firmware_blob is the content of the entire firmware flash file (for > example, > + OVMF.fd).
Lets add a caveat that the firmware flash should be built to be stateless ie that it is not secure to attempt to measure a guest where the firmware uses an NVRAM store. > +* if kernel is used, and kernel-hashes=on, then kernel_hashes_blob is the > + content of PaddedSevHashTable (including the zero padding), which itself > + includes the hashes of kernel, initrd, and cmdline that are passed to the > + guest. The PaddedSevHashTable struct is defined in target/i386/sev.c . > +* if SEV-ES is enabled (policy & 0x4 != 0), vmsas_blob is the concatenation > of > + all VMSAs of the guest vcpus. Each VMSA is 4096 bytes long; its content is > + defined inside Linux kernel code as struct vmcb_save_area, or in AMD APM > + Volume 2 [2] Table B-2: VMCB Layout, State Save Area. Is there any practical guidance we can give apps on the way the VMSAs can be expected to be initialized ? eg can they assume essentially all fields in vmcb_save_area are 0 initialized except for certain ones ? Is initialization likely to vary at all across KVM or EDK2 vesions or something ? > + > +If kernel hashes are not used, or SEV-ES is disabled, use empty blobs for > +kernel_hashes_blob and vmsas_blob as needed. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
