[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [PATCH v7 08/26] docs: add AMD Secure Encrypted Virtualizat
[Qemu-devel] [PATCH v7 08/26] docs: add AMD Secure Encrypted Virtualization (SEV)
Wed, 7 Feb 2018 10:06:20 -0600
Create a documentation entry to describe the AMD Secure Encrypted
Virtualization (SEV) feature.
Cc: Paolo Bonzini <address@hidden>
Signed-off-by: Brijesh Singh <address@hidden>
docs/amd-memory-encryption.txt | 92 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 92 insertions(+)
create mode 100644 docs/amd-memory-encryption.txt
diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
new file mode 100644
@@ -0,0 +1,92 @@
+Secure Encrypted Virtualization (SEV) is a feature found on AMD processors.
+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
+(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
+key; if its data is accessed to a different entity using a different key the
+encrypted guests data will be incorrectly decrypted, leading to unintelligible
+The key management of this feature is handled by separate processor known as
+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
+includes commands for launching, snapshotting, migrating and debugging the
+encrypted guest. Those SEV command can be issued via KVM_MEMORY_ENCRYPT_OP
+Boot images (such as bios) must be encrypted before guest can be booted.
+MEMORY_ENCRYPT_OP ioctl provides commands to encrypt the images :LAUNCH_START,
+LAUNCH_UPDATE_DATA, LAUNCH_MEASURE and LAUNCH_FINISH. These four commands
+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
+LAUNCH_START is called first to create a cryptographic launch context within
+the firmware. To create this context, guest owner must provides guest policy,
+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.
+The guest policy is passed as plaintext and hypervisor may able 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 running SEV guest.
+See KM Spec section 3 and 6.2 for more details.
+Guest owners 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.
+LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context
+created via 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 command 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
+LAUNCH_FINISH command finalizes the guest launch and destroy's the
+See SEV KM API Spec  'Launching a guest' usage flow (Appendix A) for the
+complete flow chart.
+Since memory contents of SEV guest is encrypted hence hypervisor access to the
+guest memory will get a cipher text. If guest policy allows debugging, then
+hypervisor can use DEBUG_DECRYPT and DEBUG_ENCRYPT commands access the guest
+memory region for debug purposes.
+AMD Memory Encryption whitepaper:
+Secure Encrypted Virutualization Key Management:
+ http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf
+KVM Forum slides:
+AMD64 Architecture Programmer's Manual:
+ SME is section 7.10
+ SEV is section 15.34
- Re: [Qemu-devel] [PATCH v7 02/26] exec: add ram_debug_ops support, (continued)
- [Qemu-devel] [PATCH v7 03/26] exec: add debug version of physical memory read and write API, Brijesh Singh, 2018/02/07
- [Qemu-devel] [PATCH v7 05/26] target/i386: add memory encryption feature cpuid support, Brijesh Singh, 2018/02/07
- [Qemu-devel] [PATCH v7 04/26] monitor/i386: use debug APIs when accessing guest memory, Brijesh Singh, 2018/02/07
- [Qemu-devel] [PATCH v7 06/26] machine: add -memory-encryption property, Brijesh Singh, 2018/02/07
- [Qemu-devel] [PATCH v7 07/26] kvm: update kvm.h to include memory encryption ioctls, Brijesh Singh, 2018/02/07
- [Qemu-devel] [PATCH v7 08/26] docs: add AMD Secure Encrypted Virtualization (SEV),
Brijesh Singh <=
- [Qemu-devel] [PATCH v7 11/26] sev: register the guest memory range which may contain encrypted data, Brijesh Singh, 2018/02/07
- [Qemu-devel] [PATCH v7 09/26] accel: add Secure Encrypted Virtulization (SEV) object, Brijesh Singh, 2018/02/07
- [Qemu-devel] [PATCH v7 10/26] sev: add command to initialize the memory encryption context, Brijesh Singh, 2018/02/07
- [Qemu-devel] [PATCH v7 13/26] qmp: add query-sev command, Brijesh Singh, 2018/02/07
- [Qemu-devel] [PATCH v7 14/26] hmp: add 'info sev' command, Brijesh Singh, 2018/02/07
- [Qemu-devel] [PATCH v7 17/26] target/i386: encrypt bios rom, Brijesh Singh, 2018/02/07