From 1bd5660666d2a1f704ebabeed8a2bbfa02410f41 Mon Sep 17 00:00:00 2001

From: Connor Kuehl <ckuehl@redhat.com>

Date: Tue, 22 Jun 2021 20:00:21 -0400

Subject: [PATCH 09/12] docs: Add SEV-ES documentation to

 amd-memory-encryption.txt

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

RH-Author: Miroslav Rezanina <mrezanin@redhat.com>

RH-MergeRequest: 16: Synchronize with RHEL-AV 8.5 release 21 to RHEL 9

RH-Commit: [7/8] 36e49577484813866132b90c64cf99779326db74 (mrezanin/centos-src-qemu-kvm)

RH-Bugzilla: 1957194

RH-Acked-by: Vitaly Kuznetsov <vkuznets@redhat.com>

RH-Acked-by: Daniel P. Berrangé <berrange@redhat.com>

From: Tom Lendacky <thomas.lendacky@amd.com>

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>

(cherry picked from commit 61b7d7098cd53dd386939610d534f8bd79240881)

Signed-off-by: Connor Kuehl <ckuehl@redhat.com>

Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>

Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>

---

 docs/amd-memory-encryption.txt | 54 +++++++++++++++++++++++++++++-----

 1 file changed, 47 insertions(+), 7 deletions(-)

diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt

index ed85159ea7..ffca382b5f 100644

--- a/docs/amd-memory-encryption.txt

+++ b/docs/amd-memory-encryption.txt

@@ -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

-- 

2.27.0