ShuriZma
/
xemu
mirror of https://github.com/xemu-project/xemu.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: Fix some mistakes in the SEV documentation 

Fix some spelling and grammar mistakes in the amd-memory-encryption.txt
file. No new information added.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Connor Kuehl <ckuehl@redhat.com>
Message-Id: <a7c5ee6c056d840f46028f4a817c16a9862bdd9e.1619208498.git.thomas.lendacky@amd.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
This commit is contained in:
Tom Lendacky 2021-04-23 15:08:17 -05:00 committed by Eduardo Habkost
parent 035d1ef265
commit f538adeccf
1 changed files with 29 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
docs/amd-memory-encryption.txt
View File

@ -1,38 +1,38 @@
Secure Encrypted Virtualization (SEV) is a feature found on AMD processors. Secure Encrypted Virtualization (SEV) is a feature found on AMD processors.
SEV is an extension to the AMD-V architecture which supports running encrypted SEV is an extension to the AMD-V architecture which supports running encrypted
virtual machine (VMs) under the control of KVM. Encrypted VMs have their pages virtual machines (VMs) under the control of KVM. Encrypted VMs have their pages
(code and data) secured such that only the guest itself has access to the (code and data) secured such that only the guest itself has access to the
unencrypted version. Each encrypted VM is associated with a unique encryption unencrypted version. Each encrypted VM is associated with a unique encryption
key; if its data is accessed to a different entity using a different key the key; if its data is accessed by a different entity using a different key the
encrypted guests data will be incorrectly decrypted, leading to unintelligible encrypted guests data will be incorrectly decrypted, leading to unintelligible
data. data.
The key management of this feature is handled by separate processor known as Key management for this feature is handled by a separate processor known as the
AMD secure processor (AMD-SP) which is present in AMD SOCs. Firmware running AMD secure processor (AMD-SP), which is present in AMD SOCs. Firmware running
inside the AMD-SP provide commands to support common VM lifecycle. This inside the AMD-SP provides commands to support a common VM lifecycle. This
includes commands for launching, snapshotting, migrating and debugging the includes commands for launching, snapshotting, migrating and debugging the
encrypted guest. Those SEV command can be issued via KVM_MEMORY_ENCRYPT_OP encrypted guest. These SEV commands can be issued via KVM_MEMORY_ENCRYPT_OP
ioctls. ioctls.
Launching Launching
--------- ---------
Boot images (such as bios) must be encrypted before guest can be booted. Boot images (such as bios) must be encrypted before a guest can be booted. The
MEMORY_ENCRYPT_OP ioctl provides commands to encrypt the images :LAUNCH_START, MEMORY_ENCRYPT_OP ioctl provides commands to encrypt the images: LAUNCH_START,
LAUNCH_UPDATE_DATA, LAUNCH_MEASURE and LAUNCH_FINISH. These four commands LAUNCH_UPDATE_DATA, LAUNCH_MEASURE and LAUNCH_FINISH. These four commands
together generate a fresh memory encryption key for the VM, encrypt the boot 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 the images and provide a measurement than can be used as an attestation of a
successful launch. successful launch.
LAUNCH_START is called first to create a cryptographic launch context within LAUNCH_START is called first to create a cryptographic launch context within
the firmware. To create this context, guest owner must provides guest policy, the firmware. To create this context, guest owner must provide a guest policy,
its public Diffie-Hellman key (PDH) and session parameters. These inputs its public Diffie-Hellman key (PDH) and session parameters. These inputs
should be treated as binary blob and must be passed as-is to the SEV firmware. should be treated as a binary blob and must be passed as-is to the SEV firmware.
The guest policy is passed as plaintext and hypervisor may able to read it 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 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 in bad measurement). The guest policy is a 4-byte data structure containing
several flags that restricts what can be done on running SEV guest. 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 KM Spec section 3 and 6.2 for more details.
The guest policy can be provided via the 'policy' property (see below) The guest policy can be provided via the 'policy' property (see below)
@ -40,31 +40,30 @@ The guest policy can be provided via the 'policy' property (see below)
# ${QEMU} \ # ${QEMU} \
sev-guest,id=sev0,policy=0x1...\ sev-guest,id=sev0,policy=0x1...\
Guest owners provided DH certificate and session parameters will be used to 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 establish a cryptographic session with the guest owner to negotiate keys used
for the attestation. for the attestation.
The DH certificate and session blob can be provided via 'dh-cert-file' and The DH certificate and session blob can be provided via the 'dh-cert-file' and
'session-file' property (see below 'session-file' properties (see below)
# ${QEMU} \ # ${QEMU} \
sev-guest,id=sev0,dh-cert-file=<file1>,session-file=<file2> sev-guest,id=sev0,dh-cert-file=<file1>,session-file=<file2>
LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context
created via LAUNCH_START command. If required, this command can be called created via the LAUNCH_START command. If required, this command can be called
multiple times to encrypt different memory regions. The command also calculates multiple times to encrypt different memory regions. The command also calculates
the measurement of the memory contents as it encrypts. the measurement of the memory contents as it encrypts.
LAUNCH_MEASURE command can be used to retrieve the measurement of encrypted LAUNCH_MEASURE can be used to retrieve the measurement of encrypted memory.
memory. This measurement is a signature of the memory contents that can be This measurement is a signature of the memory contents that can be sent to the
sent to the guest owner as an attestation that the memory was encrypted guest owner as an attestation that the memory was encrypted correctly by the
correctly by the firmware. The guest owner may wait to provide the guest firmware. The guest owner may wait to provide the guest confidential information
confidential information until it can verify the attestation measurement. until it can verify the attestation measurement. Since the guest owner knows the
Since the guest owner knows the initial contents of the guest at boot, the initial contents of the guest at boot, the attestation measurement can be
attestation measurement can be verified by comparing it to what the guest owner verified by comparing it to what the guest owner expects.
expects.
LAUNCH_FINISH command finalizes the guest launch and destroy's the cryptographic LAUNCH_FINISH finalizes the guest launch and destroys the cryptographic
context. context.
See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the
@ -78,10 +77,10 @@ To launch a SEV guest
Debugging Debugging
----------- -----------
Since memory contents of SEV guest is encrypted hence hypervisor access to the Since the memory contents of a SEV guest are encrypted, hypervisor access to
guest memory will get a cipher text. If guest policy allows debugging, then the guest memory will return cipher text. If the guest policy allows debugging,
hypervisor can use DEBUG_DECRYPT and DEBUG_ENCRYPT commands access the guest then a hypervisor can use the DEBUG_DECRYPT and DEBUG_ENCRYPT commands to access
memory region for debug purposes. This is not supported in QEMU yet. the guest memory region for debug purposes. This is not supported in QEMU yet.
Snapshot/Restore Snapshot/Restore
----------------- -----------------