docs: Add SEV-ES documentation to amd-memory-encryption.txt
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> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Connor Kuehl <ckuehl@redhat.com> Message-Id: <fa1825a5eb0290eac4712cde75ba4c6829946eac.1619208498.git.thomas.lendacky@amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
This commit is contained in:
Tom Lendacky
Eduardo Habkost
parent
f538adeccf
commit
61b7d7098c
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue