qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] docs: Add SEV-ES documentation to amd-memory-encryption.txt


From: Tom Lendacky
Subject: Re: [PATCH] docs: Add SEV-ES documentation to amd-memory-encryption.txt
Date: Wed, 21 Apr 2021 14:31:13 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

On 4/21/21 2:12 PM, Tom Lendacky wrote:
> 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.
> 

Hmm, it occurs to me that I should also mention some of the launch
restrictions between SEV and SEV-ES - such as not supporting SMM or reboot
in SEV-ES because of the requirements to modify the guest register state.

I'll wait for feedback on this version and send out a v2 with the added
information.

Thanks,
Tom

> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  docs/amd-memory-encryption.txt | 45 ++++++++++++++++++++++++++++------
>  1 file changed, 37 insertions(+), 8 deletions(-)
> 
> diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
> index 145896aec7..795b990fab 100644
> --- a/docs/amd-memory-encryption.txt
> +++ b/docs/amd-memory-encryption.txt
> @@ -12,18 +12,28 @@ 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
> +encrypted guest. Those 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 guest can be booted.
> -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
>  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
>  successful launch.
>  
> +For an 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 provides guest policy,
>  its public Diffie-Hellman key (PDH) and session parameters. These inputs
> @@ -40,31 +50,42 @@ 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 an
> +SEV-ES guest (see below)
> +
> +# ${QEMU} \
> +   sev-guest,id=sev0,policy=0x5...\
> +
>  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.
>  
>  The DH certificate and session blob can be provided via 'dh-cert-file' and
> -'session-file' property (see below
> +'session-file' property (see below)
>  
>  # ${QEMU} \
>       sev-guest,id=sev0,dh-cert-file=<file1>,session-file=<file2>
>  
>  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
>  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
> +LAUNCH_UPDATE_VMSA encrypts all the vCPU VMSAs for an 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 an SEV-ES guest, encrypted VMSAs. This measurement is a signature of the
> +memory contents and, for an 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 command finalizes the guest launch and destroy's the 
> cryptographic
> +LAUNCH_FINISH command finalizes the guest launch and destroys the 
> cryptographic
>  context.
>  
>  See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the
> @@ -76,6 +97,12 @@ 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
> +
>  Debugging
>  -----------
>  Since memory contents of SEV guest is encrypted hence hypervisor access to 
> the
> @@ -102,8 +129,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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]