| Message ID | fa1825a5eb0290eac4712cde75ba4c6829946eac.1619208498.git.thomas.lendacky@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/3] doc: Fix some mistakes in the SEV documentation | expand |
On 04/23/21 22:08, Tom Lendacky wrote: > From: Tom Lendacky <thomas.lendacky@amd.com> > > Update the amd-memory-encryption.txt file with information about SEV-ES, > including how to launch an SEV-ES guest and some of the differences > between SEV and SEV-ES guests in regards to launching and measuring the > guest. > > Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> > --- > docs/amd-memory-encryption.txt | 54 +++++++++++++++++++++++++++++----- > 1 file changed, 47 insertions(+), 7 deletions(-) > > diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt > index ed85159ea7..ffca382b5f 100644 > --- a/docs/amd-memory-encryption.txt > +++ b/docs/amd-memory-encryption.txt > @@ -15,6 +15,13 @@ includes commands for launching, snapshotting, migrating and debugging the > encrypted guest. These SEV commands can be issued via KVM_MEMORY_ENCRYPT_OP > ioctls. > > +Secure Encrypted Virtualization - Encrypted State (SEV-ES) builds on the SEV > +support to additionally protect the guest register state. In order to allow a > +hypervisor to perform functions on behalf of a guest, there is architectural > +support for notifying a guest's operating system when certain types of VMEXITs > +are about to occur. This allows the guest to selectively share information with > +the hypervisor to satisfy the requested function. > + > Launching > --------- > Boot images (such as bios) must be encrypted before a guest can be booted. The > @@ -24,6 +31,9 @@ together generate a fresh memory encryption key for the VM, encrypt the boot > images and provide a measurement than can be used as an attestation of a > successful launch. > > +For a SEV-ES guest, the LAUNCH_UPDATE_VMSA command is also used to encrypt the > +guest register state, or VM save area (VMSA), for all of the guest vCPUs. > + > LAUNCH_START is called first to create a cryptographic launch context within > the firmware. To create this context, guest owner must provide a guest policy, > its public Diffie-Hellman key (PDH) and session parameters. These inputs > @@ -40,6 +50,12 @@ The guest policy can be provided via the 'policy' property (see below) > # ${QEMU} \ > sev-guest,id=sev0,policy=0x1...\ > > +Setting the "SEV-ES required" policy bit (bit 2) will launch the guest as a > +SEV-ES guest (see below) > + > +# ${QEMU} \ > + sev-guest,id=sev0,policy=0x5...\ > + > The guest owner provided DH certificate and session parameters will be used to > establish a cryptographic session with the guest owner to negotiate keys used > for the attestation. > @@ -55,13 +71,19 @@ created via the LAUNCH_START command. If required, this command can be called > multiple times to encrypt different memory regions. The command also calculates > the measurement of the memory contents as it encrypts. > > -LAUNCH_MEASURE can be used to retrieve the measurement of encrypted memory. > -This measurement is a signature of the memory contents that can be sent to the > -guest owner as an attestation that the memory was encrypted correctly by the > -firmware. The guest owner may wait to provide the guest confidential information > -until it can verify the attestation measurement. Since the guest owner knows the > -initial contents of the guest at boot, the attestation measurement can be > -verified by comparing it to what the guest owner expects. > +LAUNCH_UPDATE_VMSA encrypts all the vCPU VMSAs for a SEV-ES guest using the > +cryptographic context created via the LAUNCH_START command. The command also > +calculates the measurement of the VMSAs as it encrypts them. > + > +LAUNCH_MEASURE can be used to retrieve the measurement of encrypted memory and, > +for a SEV-ES guest, encrypted VMSAs. This measurement is a signature of the > +memory contents and, for a SEV-ES guest, the VMSA contents, that can be sent > +to the guest owner as an attestation that the memory and VMSAs were encrypted > +correctly by the firmware. The guest owner may wait to provide the guest > +confidential information until it can verify the attestation measurement. > +Since the guest owner knows the initial contents of the guest at boot, the > +attestation measurement can be verified by comparing it to what the guest owner > +expects. > > LAUNCH_FINISH finalizes the guest launch and destroys the cryptographic > context. > @@ -75,6 +97,22 @@ To launch a SEV guest > -machine ...,confidential-guest-support=sev0 \ > -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1 > > +To launch a SEV-ES guest > + > +# ${QEMU} \ > + -machine ...,confidential-guest-support=sev0 \ > + -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x5 > + > +An SEV-ES guest has some restrictions as compared to a SEV guest. Because the > +guest register state is encrypted and cannot be updated by the VMM/hypervisor, > +a SEV-ES guest: > + - Does not support SMM - SMM support requires updating the guest register > + state. > + - Does not support reboot - a system reset requires updating the guest register > + state. > + - Requires in-kernel irqchip - the burden is placed on the hypervisor to > + manage booting APs. > + > Debugging > ----------- > Since the memory contents of a SEV guest are encrypted, hypervisor access to > @@ -101,8 +139,10 @@ Secure Encrypted Virtualization Key Management: > > KVM Forum slides: > http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf > +https://www.linux-kvm.org/images/9/94/Extending-Secure-Encrypted-Virtualization-with-SEV-ES-Thomas-Lendacky-AMD.pdf > > AMD64 Architecture Programmer's Manual: > http://support.amd.com/TechDocs/24593.pdf > SME is section 7.10 > SEV is section 15.34 > + SEV-ES is section 15.35 > Looks good to me. Acked-by: Laszlo Ersek <lersek@redhat.com>
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt index ed85159ea7..ffca382b5f 100644 --- a/docs/amd-memory-encryption.txt +++ b/docs/amd-memory-encryption.txt @@ -15,6 +15,13 @@ includes commands for launching, snapshotting, migrating and debugging the encrypted guest. These SEV commands can be issued via KVM_MEMORY_ENCRYPT_OP ioctls. +Secure Encrypted Virtualization - Encrypted State (SEV-ES) builds on the SEV +support to additionally protect the guest register state. In order to allow a +hypervisor to perform functions on behalf of a guest, there is architectural +support for notifying a guest's operating system when certain types of VMEXITs +are about to occur. This allows the guest to selectively share information with +the hypervisor to satisfy the requested function. + Launching --------- Boot images (such as bios) must be encrypted before a guest can be booted. The @@ -24,6 +31,9 @@ together generate a fresh memory encryption key for the VM, encrypt the boot images and provide a measurement than can be used as an attestation of a successful launch. +For a SEV-ES guest, the LAUNCH_UPDATE_VMSA command is also used to encrypt the +guest register state, or VM save area (VMSA), for all of the guest vCPUs. + LAUNCH_START is called first to create a cryptographic launch context within the firmware. To create this context, guest owner must provide a guest policy, its public Diffie-Hellman key (PDH) and session parameters. These inputs @@ -40,6 +50,12 @@ The guest policy can be provided via the 'policy' property (see below) # ${QEMU} \ sev-guest,id=sev0,policy=0x1...\ +Setting the "SEV-ES required" policy bit (bit 2) will launch the guest as a +SEV-ES guest (see below) + +# ${QEMU} \ + sev-guest,id=sev0,policy=0x5...\ + The guest owner provided DH certificate and session parameters will be used to establish a cryptographic session with the guest owner to negotiate keys used for the attestation. @@ -55,13 +71,19 @@ created via the LAUNCH_START command. If required, this command can be called multiple times to encrypt different memory regions. The command also calculates the measurement of the memory contents as it encrypts. -LAUNCH_MEASURE can be used to retrieve the measurement of encrypted memory. -This measurement is a signature of the memory contents that can be sent to the -guest owner as an attestation that the memory was encrypted correctly by the -firmware. The guest owner may wait to provide the guest confidential information -until it can verify the attestation measurement. Since the guest owner knows the -initial contents of the guest at boot, the attestation measurement can be -verified by comparing it to what the guest owner expects. +LAUNCH_UPDATE_VMSA encrypts all the vCPU VMSAs for a SEV-ES guest using the +cryptographic context created via the LAUNCH_START command. The command also +calculates the measurement of the VMSAs as it encrypts them. + +LAUNCH_MEASURE can be used to retrieve the measurement of encrypted memory and, +for a SEV-ES guest, encrypted VMSAs. This measurement is a signature of the +memory contents and, for a SEV-ES guest, the VMSA contents, that can be sent +to the guest owner as an attestation that the memory and VMSAs were encrypted +correctly by the firmware. The guest owner may wait to provide the guest +confidential information until it can verify the attestation measurement. +Since the guest owner knows the initial contents of the guest at boot, the +attestation measurement can be verified by comparing it to what the guest owner +expects. LAUNCH_FINISH finalizes the guest launch and destroys the cryptographic context. @@ -75,6 +97,22 @@ To launch a SEV guest -machine ...,confidential-guest-support=sev0 \ -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1 +To launch a SEV-ES guest + +# ${QEMU} \ + -machine ...,confidential-guest-support=sev0 \ + -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1,policy=0x5 + +An SEV-ES guest has some restrictions as compared to a SEV guest. Because the +guest register state is encrypted and cannot be updated by the VMM/hypervisor, +a SEV-ES guest: + - Does not support SMM - SMM support requires updating the guest register + state. + - Does not support reboot - a system reset requires updating the guest register + state. + - Requires in-kernel irqchip - the burden is placed on the hypervisor to + manage booting APs. + Debugging ----------- Since the memory contents of a SEV guest are encrypted, hypervisor access to @@ -101,8 +139,10 @@ Secure Encrypted Virtualization Key Management: KVM Forum slides: http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf +https://www.linux-kvm.org/images/9/94/Extending-Secure-Encrypted-Virtualization-with-SEV-ES-Thomas-Lendacky-AMD.pdf AMD64 Architecture Programmer's Manual: http://support.amd.com/TechDocs/24593.pdf SME is section 7.10 SEV is section 15.34 + SEV-ES is section 15.35