1Secure Encrypted Virtualization (SEV) is a feature found on AMD processors. 2 3SEV is an extension to the AMD-V architecture which supports running encrypted 4virtual machine (VMs) under the control of KVM. Encrypted VMs have their pages 5(code and data) secured such that only the guest itself has access to the 6unencrypted version. Each encrypted VM is associated with a unique encryption 7key; if its data is accessed to a different entity using a different key the 8encrypted guests data will be incorrectly decrypted, leading to unintelligible 9data. 10 11The key management of this feature is handled by separate processor known as 12AMD secure processor (AMD-SP) which is present in AMD SOCs. Firmware running 13inside the AMD-SP provide commands to support common VM lifecycle. This 14includes commands for launching, snapshotting, migrating and debugging the 15encrypted guest. Those SEV command can be issued via KVM_MEMORY_ENCRYPT_OP 16ioctls. 17 18Launching 19--------- 20Boot images (such as bios) must be encrypted before guest can be booted. 21MEMORY_ENCRYPT_OP ioctl provides commands to encrypt the images :LAUNCH_START, 22LAUNCH_UPDATE_DATA, LAUNCH_MEASURE and LAUNCH_FINISH. These four commands 23together generate a fresh memory encryption key for the VM, encrypt the boot 24images and provide a measurement than can be used as an attestation of the 25successful launch. 26 27LAUNCH_START is called first to create a cryptographic launch context within 28the firmware. To create this context, guest owner must provides guest policy, 29its public Diffie-Hellman key (PDH) and session parameters. These inputs 30should be treated as binary blob and must be passed as-is to the SEV firmware. 31 32The guest policy is passed as plaintext and hypervisor may able to read it 33but should not modify it (any modification of the policy bits will result 34in bad measurement). The guest policy is a 4-byte data structure containing 35several flags that restricts what can be done on running SEV guest. 36See KM Spec section 3 and 6.2 for more details. 37 38The guest policy can be provided via the 'policy' property (see below) 39 40# ${QEMU} \ 41 sev-guest,id=sev0,policy=0x1...\ 42 43Guest owners provided DH certificate and session parameters will be used to 44establish a cryptographic session with the guest owner to negotiate keys used 45for the attestation. 46 47The DH certificate and session blob can be provided via 'dh-cert-file' and 48'session-file' property (see below 49 50# ${QEMU} \ 51 sev-guest,id=sev0,dh-cert-file=<file1>,session-file=<file2> 52 53LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context 54created via LAUNCH_START command. If required, this command can be called 55multiple times to encrypt different memory regions. The command also calculates 56the measurement of the memory contents as it encrypts. 57 58LAUNCH_MEASURE command can be used to retrieve the measurement of encrypted 59memory. This measurement is a signature of the memory contents that can be 60sent to the guest owner as an attestation that the memory was encrypted 61correctly by the firmware. The guest owner may wait to provide the guest 62confidential information until it can verify the attestation measurement. 63Since the guest owner knows the initial contents of the guest at boot, the 64attestation measurement can be verified by comparing it to what the guest owner 65expects. 66 67LAUNCH_FINISH command finalizes the guest launch and destroy's the cryptographic 68context. 69 70See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the 71complete flow chart. 72 73To launch a SEV guest 74 75# ${QEMU} \ 76 -machine ...,memory-encryption=sev0 \ 77 -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1 78 79Debugging 80----------- 81Since memory contents of SEV guest is encrypted hence hypervisor access to the 82guest memory will get a cipher text. If guest policy allows debugging, then 83hypervisor can use DEBUG_DECRYPT and DEBUG_ENCRYPT commands access the guest 84memory region for debug purposes. This is not supported in QEMU yet. 85 86Snapshot/Restore 87----------------- 88TODO 89 90Live Migration 91---------------- 92TODO 93 94References 95----------------- 96 97AMD Memory Encryption whitepaper: 98http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf 99 100Secure Encrypted Virtualization Key Management: 101[1] http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf 102 103KVM Forum slides: 104http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf 105 106AMD64 Architecture Programmer's Manual: 107 http://support.amd.com/TechDocs/24593.pdf 108 SME is section 7.10 109 SEV is section 15.34 110