From: Cornelia Huck Date: Wed, 9 Feb 2022 08:08:56 +0000 (+0100) Subject: docs: rstfy confidential guest documentation X-Git-Url: http://git.maquefel.me/?a=commitdiff_plain;h=96a46def58b3b7938d200fca6bd4916c3640d2f3;p=qemu.git docs: rstfy confidential guest documentation Also rstfy the documentation for AMD SEV, and link it. The documentation for PEF had been merged into the pseries doc, fix the reference. Signed-off-by: Cornelia Huck Reviewed-by: Daniel Henrique Barboza Message-Id: <20220204161251.241877-1-cohuck@redhat.com> Signed-off-by: Cédric Le Goater --- diff --git a/MAINTAINERS b/MAINTAINERS index 9814580975..8944fb561c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -408,7 +408,7 @@ M: Paolo Bonzini M: Marcelo Tosatti L: kvm@vger.kernel.org S: Supported -F: docs/amd-memory-encryption.txt +F: docs/system/i386/amd-memory-encryption.rst F: docs/system/i386/sgx.rst F: target/i386/kvm/ F: target/i386/sev* diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt deleted file mode 100644 index ffca382b5f..0000000000 --- a/docs/amd-memory-encryption.txt +++ /dev/null @@ -1,148 +0,0 @@ -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 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 -unencrypted version. Each encrypted VM is associated with a unique encryption -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 -data. - -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 -inside the AMD-SP provides commands to support a common VM lifecycle. This -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 -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 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 -should be treated as a binary blob and must be passed as-is to the SEV firmware. - -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 -in bad measurement). The guest policy is a 4-byte data structure containing -several flags that restricts what can be done on a running SEV guest. -See KM Spec section 3 and 6.2 for more details. - -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. - -The DH certificate and session blob can be provided via the 'dh-cert-file' and -'session-file' properties (see below) - -# ${QEMU} \ - sev-guest,id=sev0,dh-cert-file=,session-file= - -LAUNCH_UPDATE_DATA encrypts the memory region using the cryptographic context -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_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. - -See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the -complete flow chart. - -To launch a SEV guest - -# ${QEMU} \ - -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 -the guest memory will return cipher text. If the guest policy allows debugging, -then a hypervisor can use the DEBUG_DECRYPT and DEBUG_ENCRYPT commands to access -the guest memory region for debug purposes. This is not supported in QEMU yet. - -Snapshot/Restore ------------------ -TODO - -Live Migration ----------------- -TODO - -References ------------------ - -AMD Memory Encryption whitepaper: -https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf - -Secure Encrypted Virtualization Key Management: -[1] http://developer.amd.com/wordpress/media/2017/11/55766_SEV-KM-API_Specification.pdf - -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 diff --git a/docs/confidential-guest-support.txt b/docs/confidential-guest-support.txt deleted file mode 100644 index 71d07ba57a..0000000000 --- a/docs/confidential-guest-support.txt +++ /dev/null @@ -1,49 +0,0 @@ -Confidential Guest Support -========================== - -Traditionally, hypervisors such as QEMU have complete access to a -guest's memory and other state, meaning that a compromised hypervisor -can compromise any of its guests. A number of platforms have added -mechanisms in hardware and/or firmware which give guests at least some -protection from a compromised hypervisor. This is obviously -especially desirable for public cloud environments. - -These mechanisms have different names and different modes of -operation, but are often referred to as Secure Guests or Confidential -Guests. We use the term "Confidential Guest Support" to distinguish -this from other aspects of guest security (such as security against -attacks from other guests, or from network sources). - -Running a Confidential Guest ----------------------------- - -To run a confidential guest you need to add two command line parameters: - -1. Use "-object" to create a "confidential guest support" object. The - type and parameters will vary with the specific mechanism to be - used -2. Set the "confidential-guest-support" machine parameter to the ID of - the object from (1). - -Example (for AMD SEV):: - - qemu-system-x86_64 \ - \ - -machine ...,confidential-guest-support=sev0 \ - -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1 - -Supported mechanisms --------------------- - -Currently supported confidential guest mechanisms are: - -AMD Secure Encrypted Virtualization (SEV) - docs/amd-memory-encryption.txt - -POWER Protected Execution Facility (PEF) - docs/papr-pef.txt - -s390x Protected Virtualization (PV) - docs/system/s390x/protvirt.rst - -Other mechanisms may be supported in future. diff --git a/docs/system/confidential-guest-support.rst b/docs/system/confidential-guest-support.rst new file mode 100644 index 0000000000..0c490dbda2 --- /dev/null +++ b/docs/system/confidential-guest-support.rst @@ -0,0 +1,44 @@ +Confidential Guest Support +========================== + +Traditionally, hypervisors such as QEMU have complete access to a +guest's memory and other state, meaning that a compromised hypervisor +can compromise any of its guests. A number of platforms have added +mechanisms in hardware and/or firmware which give guests at least some +protection from a compromised hypervisor. This is obviously +especially desirable for public cloud environments. + +These mechanisms have different names and different modes of +operation, but are often referred to as Secure Guests or Confidential +Guests. We use the term "Confidential Guest Support" to distinguish +this from other aspects of guest security (such as security against +attacks from other guests, or from network sources). + +Running a Confidential Guest +---------------------------- + +To run a confidential guest you need to add two command line parameters: + +1. Use ``-object`` to create a "confidential guest support" object. The + type and parameters will vary with the specific mechanism to be + used +2. Set the ``confidential-guest-support`` machine parameter to the ID of + the object from (1). + +Example (for AMD SEV):: + + qemu-system-x86_64 \ + \ + -machine ...,confidential-guest-support=sev0 \ + -object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=1 + +Supported mechanisms +-------------------- + +Currently supported confidential guest mechanisms are: + +* AMD Secure Encrypted Virtualization (SEV) (see :doc:`i386/amd-memory-encryption`) +* POWER Protected Execution Facility (PEF) (see :ref:`power-papr-protected-execution-facility-pef`) +* s390x Protected Virtualization (PV) (see :doc:`s390x/protvirt`) + +Other mechanisms may be supported in future. diff --git a/docs/system/i386/amd-memory-encryption.rst b/docs/system/i386/amd-memory-encryption.rst new file mode 100644 index 0000000000..215946f813 --- /dev/null +++ b/docs/system/i386/amd-memory-encryption.rst @@ -0,0 +1,160 @@ +AMD Secure Encrypted Virtualization (SEV) +========================================= + +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 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 +unencrypted version. Each encrypted VM is associated with a unique encryption +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 +data. + +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 +inside the AMD-SP provides commands to support a common VM lifecycle. This +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 +``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 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 +should be treated as a binary blob and must be passed as-is to the SEV firmware. + +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 +in bad measurement). The guest policy is a 4-byte data structure containing +several flags that restricts what can be done on a running SEV guest. +See KM Spec section 3 and 6.2 for more details. + +The guest policy can be provided via the ``policy`` property:: + + # ${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:: + + # ${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. + +The DH certificate and session blob can be provided via the ``dh-cert-file`` and +``session-file`` properties:: + + # ${QEMU} \ + sev-guest,id=sev0,dh-cert-file=,session-file= + +``LAUNCH_UPDATE_DATA`` encrypts the memory region using the cryptographic context +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_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. + +See SEV KM API Spec ([SEVKM]_) 'Launching a guest' usage flow (Appendix A) for the +complete flow chart. + +To launch a SEV guest:: + + # ${QEMU} \ + -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 +the guest memory will return cipher text. If the guest policy allows debugging, +then a hypervisor can use the DEBUG_DECRYPT and DEBUG_ENCRYPT commands to access +the guest memory region for debug purposes. This is not supported in QEMU yet. + +Snapshot/Restore +---------------- + +TODO + +Live Migration +--------------- + +TODO + +References +---------- + +`AMD Memory Encryption whitepaper +`_ + +.. [SEVKM] `Secure Encrypted Virtualization Key Management + `_ + +KVM Forum slides: + +* `AMD’s Virtualization Memory Encryption (2016) + `_ +* `Extending Secure Encrypted Virtualization With SEV-ES (2018) + `_ + +`AMD64 Architecture Programmer's Manual: +`_ + +* SME is section 7.10 +* SEV is section 15.34 +* SEV-ES is section 15.35 diff --git a/docs/system/index.rst b/docs/system/index.rst index 73bbedbc22..23e30e26e5 100644 --- a/docs/system/index.rst +++ b/docs/system/index.rst @@ -34,3 +34,4 @@ or Hypervisor.Framework. targets security multi-process + confidential-guest-support diff --git a/docs/system/ppc/pseries.rst b/docs/system/ppc/pseries.rst index 569237dc0c..d9b65ad4e8 100644 --- a/docs/system/ppc/pseries.rst +++ b/docs/system/ppc/pseries.rst @@ -224,6 +224,8 @@ nested. Combinations not shown in the table are not available. .. [3] Introduced on Power10 machines. +.. _power-papr-protected-execution-facility-pef: + POWER (PAPR) Protected Execution Facility (PEF) ----------------------------------------------- diff --git a/docs/system/target-i386.rst b/docs/system/target-i386.rst index 4daa53c35d..96bf54889a 100644 --- a/docs/system/target-i386.rst +++ b/docs/system/target-i386.rst @@ -28,6 +28,7 @@ Architectural features i386/cpu i386/kvm-pv i386/sgx + i386/amd-memory-encryption .. _pcsys_005freq: