* [PATCH v2 2/3] docs: Add SEV-ES documentation to amd-memory-encryption.txt
2021-04-23 20:08 [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation Tom Lendacky
@ 2021-04-23 20:08 ` Tom Lendacky
2021-04-26 12:33 ` Laszlo Ersek
2021-04-23 20:08 ` [PATCH v2 3/3] docs/interop/firmware.json: Add SEV-ES support Tom Lendacky
` (3 subsequent siblings)
4 siblings, 1 reply; 10+ messages in thread
From: Tom Lendacky @ 2021-04-23 20:08 UTC (permalink / raw)
To: qemu-devel
Cc: Pavel Hrdina, Daniel P . Berrange, Eduardo Habkost,
Michal Privoznik, Dr. David Alan Gilbert, Brijesh Singh,
Paolo Bonzini, Laszlo Ersek
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>
---
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.31.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2 2/3] docs: Add SEV-ES documentation to amd-memory-encryption.txt
2021-04-23 20:08 ` [PATCH v2 2/3] docs: Add SEV-ES documentation to amd-memory-encryption.txt Tom Lendacky
@ 2021-04-26 12:33 ` Laszlo Ersek
0 siblings, 0 replies; 10+ messages in thread
From: Laszlo Ersek @ 2021-04-26 12:33 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel
Cc: Pavel Hrdina, Daniel P . Berrange, Eduardo Habkost,
Michal Privoznik, Dr. David Alan Gilbert, Brijesh Singh,
Paolo Bonzini
On 04/23/21 22:08, 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.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.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
>
Looks good to me.
Acked-by: Laszlo Ersek <lersek@redhat.com>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 3/3] docs/interop/firmware.json: Add SEV-ES support
2021-04-23 20:08 [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation Tom Lendacky
2021-04-23 20:08 ` [PATCH v2 2/3] docs: Add SEV-ES documentation to amd-memory-encryption.txt Tom Lendacky
@ 2021-04-23 20:08 ` Tom Lendacky
2021-04-26 12:39 ` Laszlo Ersek
2021-04-26 12:11 ` [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation Laszlo Ersek
` (2 subsequent siblings)
4 siblings, 1 reply; 10+ messages in thread
From: Tom Lendacky @ 2021-04-23 20:08 UTC (permalink / raw)
To: qemu-devel
Cc: Pavel Hrdina, Daniel P . Berrange, Eduardo Habkost,
Michal Privoznik, Dr. David Alan Gilbert, Brijesh Singh,
Paolo Bonzini, Laszlo Ersek
From: Tom Lendacky <thomas.lendacky@amd.com>
Create an enum definition, '@amd-sev-es', for SEV-ES and add documention
for the new enum. Add an example that shows some of the requirements for
SEV-ES, including not having SMM support and the requirement for an
X64-only build.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
docs/interop/firmware.json | 47 +++++++++++++++++++++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json
index 9d94ccafa9..8d8b0be030 100644
--- a/docs/interop/firmware.json
+++ b/docs/interop/firmware.json
@@ -115,6 +115,12 @@
# this feature are documented in
# "docs/amd-memory-encryption.txt".
#
+# @amd-sev-es: The firmware supports running under AMD Secure Encrypted
+# Virtualization - Encrypted State, as specified in the AMD64
+# Architecture Programmer's Manual. QEMU command line options
+# related to this feature are documented in
+# "docs/amd-memory-encryption.txt".
+#
# @enrolled-keys: The variable store (NVRAM) template associated with
# the firmware binary has the UEFI Secure Boot
# operational mode turned on, with certificates
@@ -179,7 +185,7 @@
# Since: 3.0
##
{ 'enum' : 'FirmwareFeature',
- 'data' : [ 'acpi-s3', 'acpi-s4', 'amd-sev', 'enrolled-keys',
+ 'data' : [ 'acpi-s3', 'acpi-s4', 'amd-sev', 'amd-sev-es', 'enrolled-keys',
'requires-smm', 'secure-boot', 'verbose-dynamic',
'verbose-static' ] }
@@ -504,6 +510,45 @@
# }
#
# {
+# "description": "OVMF with SEV-ES support",
+# "interface-types": [
+# "uefi"
+# ],
+# "mapping": {
+# "device": "flash",
+# "executable": {
+# "filename": "/usr/share/OVMF/OVMF_CODE.fd",
+# "format": "raw"
+# },
+# "nvram-template": {
+# "filename": "/usr/share/OVMF/OVMF_VARS.fd",
+# "format": "raw"
+# }
+# },
+# "targets": [
+# {
+# "architecture": "x86_64",
+# "machines": [
+# "pc-q35-*"
+# ]
+# }
+# ],
+# "features": [
+# "acpi-s3",
+# "amd-sev",
+# "amd-sev-es",
+# "verbose-dynamic"
+# ],
+# "tags": [
+# "-a X64",
+# "-p OvmfPkg/OvmfPkgX64.dsc",
+# "-t GCC48",
+# "-b DEBUG",
+# "-D FD_SIZE_4MB"
+# ]
+# }
+#
+# {
# "description": "UEFI firmware for ARM64 virtual machines",
# "interface-types": [
# "uefi"
--
2.31.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v2 3/3] docs/interop/firmware.json: Add SEV-ES support
2021-04-23 20:08 ` [PATCH v2 3/3] docs/interop/firmware.json: Add SEV-ES support Tom Lendacky
@ 2021-04-26 12:39 ` Laszlo Ersek
0 siblings, 0 replies; 10+ messages in thread
From: Laszlo Ersek @ 2021-04-26 12:39 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel
Cc: Pavel Hrdina, Daniel P . Berrange, Eduardo Habkost,
Michal Privoznik, Dr. David Alan Gilbert, Brijesh Singh,
Paolo Bonzini
On 04/23/21 22:08, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> Create an enum definition, '@amd-sev-es', for SEV-ES and add documention
> for the new enum. Add an example that shows some of the requirements for
> SEV-ES, including not having SMM support and the requirement for an
> X64-only build.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> docs/interop/firmware.json | 47 +++++++++++++++++++++++++++++++++++++-
> 1 file changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/docs/interop/firmware.json b/docs/interop/firmware.json
> index 9d94ccafa9..8d8b0be030 100644
> --- a/docs/interop/firmware.json
> +++ b/docs/interop/firmware.json
> @@ -115,6 +115,12 @@
> # this feature are documented in
> # "docs/amd-memory-encryption.txt".
> #
> +# @amd-sev-es: The firmware supports running under AMD Secure Encrypted
> +# Virtualization - Encrypted State, as specified in the AMD64
> +# Architecture Programmer's Manual. QEMU command line options
> +# related to this feature are documented in
> +# "docs/amd-memory-encryption.txt".
> +#
> # @enrolled-keys: The variable store (NVRAM) template associated with
> # the firmware binary has the UEFI Secure Boot
> # operational mode turned on, with certificates
> @@ -179,7 +185,7 @@
> # Since: 3.0
> ##
> { 'enum' : 'FirmwareFeature',
> - 'data' : [ 'acpi-s3', 'acpi-s4', 'amd-sev', 'enrolled-keys',
> + 'data' : [ 'acpi-s3', 'acpi-s4', 'amd-sev', 'amd-sev-es', 'enrolled-keys',
> 'requires-smm', 'secure-boot', 'verbose-dynamic',
> 'verbose-static' ] }
>
> @@ -504,6 +510,45 @@
> # }
> #
> # {
> +# "description": "OVMF with SEV-ES support",
> +# "interface-types": [
> +# "uefi"
> +# ],
> +# "mapping": {
> +# "device": "flash",
> +# "executable": {
> +# "filename": "/usr/share/OVMF/OVMF_CODE.fd",
> +# "format": "raw"
> +# },
> +# "nvram-template": {
> +# "filename": "/usr/share/OVMF/OVMF_VARS.fd",
> +# "format": "raw"
> +# }
> +# },
> +# "targets": [
> +# {
> +# "architecture": "x86_64",
> +# "machines": [
> +# "pc-q35-*"
> +# ]
> +# }
> +# ],
> +# "features": [
> +# "acpi-s3",
> +# "amd-sev",
> +# "amd-sev-es",
> +# "verbose-dynamic"
> +# ],
> +# "tags": [
> +# "-a X64",
> +# "-p OvmfPkg/OvmfPkgX64.dsc",
> +# "-t GCC48",
> +# "-b DEBUG",
> +# "-D FD_SIZE_4MB"
> +# ]
> +# }
> +#
> +# {
> # "description": "UEFI firmware for ARM64 virtual machines",
> # "interface-types": [
> # "uefi"
>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Thanks!
Laszlo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation
2021-04-23 20:08 [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation Tom Lendacky
2021-04-23 20:08 ` [PATCH v2 2/3] docs: Add SEV-ES documentation to amd-memory-encryption.txt Tom Lendacky
2021-04-23 20:08 ` [PATCH v2 3/3] docs/interop/firmware.json: Add SEV-ES support Tom Lendacky
@ 2021-04-26 12:11 ` Laszlo Ersek
2021-06-02 19:19 ` Tom Lendacky
2021-06-02 20:07 ` Connor Kuehl
4 siblings, 0 replies; 10+ messages in thread
From: Laszlo Ersek @ 2021-04-26 12:11 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel
Cc: Pavel Hrdina, Daniel P . Berrange, Eduardo Habkost,
Michal Privoznik, Dr. David Alan Gilbert, Brijesh Singh,
Paolo Bonzini
On 04/23/21 22:08, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> Fix some spelling and grammar mistakes in the amd-memory-encryption.txt
> file. No new information added.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> docs/amd-memory-encryption.txt | 59 +++++++++++++++++-----------------
> 1 file changed, 29 insertions(+), 30 deletions(-)
>
> diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
> index 145896aec7..ed85159ea7 100644
> --- a/docs/amd-memory-encryption.txt
> +++ b/docs/amd-memory-encryption.txt
> @@ -1,38 +1,38 @@
> 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
> +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 to a different entity using a different key the
> +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.
>
> -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
> +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. Those SEV command can be issued via KVM_MEMORY_ENCRYPT_OP
> +encrypted guest. These SEV commands can be issued via KVM_MEMORY_ENCRYPT_OP
> ioctls.
>
> 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,
> +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 the
> +images and provide a measurement than can be used as an attestation of a
> successful launch.
>
> LAUNCH_START is called first to create a cryptographic launch context within
> -the firmware. To create this context, guest owner must provides guest policy,
> +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 binary blob and must be passed as-is to the SEV firmware.
> +should be treated as a 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
> +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 running SEV guest.
> +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)
> @@ -40,31 +40,30 @@ The guest policy can be provided via the 'policy' property (see below)
> # ${QEMU} \
> sev-guest,id=sev0,policy=0x1...\
>
> -Guest owners provided DH certificate and session parameters will be used to
> +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 'dh-cert-file' and
> -'session-file' property (see below
> +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=<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
> -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_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_FINISH command finalizes the guest launch and destroy's the cryptographic
> +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
> @@ -78,10 +77,10 @@ To launch a SEV guest
>
> Debugging
> -----------
> -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. This is not supported in QEMU yet.
> +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
> -----------------
>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation
2021-04-23 20:08 [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation Tom Lendacky
` (2 preceding siblings ...)
2021-04-26 12:11 ` [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation Laszlo Ersek
@ 2021-06-02 19:19 ` Tom Lendacky
2021-06-03 8:29 ` Laszlo Ersek
2021-06-02 20:07 ` Connor Kuehl
4 siblings, 1 reply; 10+ messages in thread
From: Tom Lendacky @ 2021-06-02 19:19 UTC (permalink / raw)
To: qemu-devel
Cc: Daniel P . Berrange, Paolo Bonzini, Laszlo Ersek,
Dr. David Alan Gilbert, Eduardo Habkost, Pavel Hrdina,
Michal Privoznik, Brijesh Singh
Just a quick ping on this series...
Thanks,
Tom
On 4/23/21 3:08 PM, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> Fix some spelling and grammar mistakes in the amd-memory-encryption.txt
> file. No new information added.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> docs/amd-memory-encryption.txt | 59 +++++++++++++++++-----------------
> 1 file changed, 29 insertions(+), 30 deletions(-)
>
> diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
> index 145896aec7..ed85159ea7 100644
> --- a/docs/amd-memory-encryption.txt
> +++ b/docs/amd-memory-encryption.txt
> @@ -1,38 +1,38 @@
> 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
> +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 to a different entity using a different key the
> +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.
>
> -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
> +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. Those SEV command can be issued via KVM_MEMORY_ENCRYPT_OP
> +encrypted guest. These SEV commands can be issued via KVM_MEMORY_ENCRYPT_OP
> ioctls.
>
> 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,
> +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 the
> +images and provide a measurement than can be used as an attestation of a
> successful launch.
>
> LAUNCH_START is called first to create a cryptographic launch context within
> -the firmware. To create this context, guest owner must provides guest policy,
> +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 binary blob and must be passed as-is to the SEV firmware.
> +should be treated as a 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
> +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 running SEV guest.
> +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)
> @@ -40,31 +40,30 @@ The guest policy can be provided via the 'policy' property (see below)
> # ${QEMU} \
> sev-guest,id=sev0,policy=0x1...\
>
> -Guest owners provided DH certificate and session parameters will be used to
> +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 'dh-cert-file' and
> -'session-file' property (see below
> +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=<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
> -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_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_FINISH command finalizes the guest launch and destroy's the cryptographic
> +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
> @@ -78,10 +77,10 @@ To launch a SEV guest
>
> Debugging
> -----------
> -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. This is not supported in QEMU yet.
> +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
> -----------------
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation
2021-06-02 19:19 ` Tom Lendacky
@ 2021-06-03 8:29 ` Laszlo Ersek
2021-06-03 19:54 ` Eduardo Habkost
0 siblings, 1 reply; 10+ messages in thread
From: Laszlo Ersek @ 2021-06-03 8:29 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel
Cc: Pavel Hrdina, Daniel P . Berrange, Eduardo Habkost,
Michal Privoznik, Dr. David Alan Gilbert, Brijesh Singh,
Paolo Bonzini
On 06/02/21 21:19, Tom Lendacky wrote:
> Just a quick ping on this series...
Right, I'm unsure who is supposed to merge this... Do you remember who
usually merges the SEV-related patch series (plural)?
Thanks
Laszlo
>
> Thanks,
> Tom
>
> On 4/23/21 3:08 PM, Tom Lendacky wrote:
>> From: Tom Lendacky <thomas.lendacky@amd.com>
>>
>> Fix some spelling and grammar mistakes in the amd-memory-encryption.txt
>> file. No new information added.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>> docs/amd-memory-encryption.txt | 59 +++++++++++++++++-----------------
>> 1 file changed, 29 insertions(+), 30 deletions(-)
>>
>> diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
>> index 145896aec7..ed85159ea7 100644
>> --- a/docs/amd-memory-encryption.txt
>> +++ b/docs/amd-memory-encryption.txt
>> @@ -1,38 +1,38 @@
>> 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
>> +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 to a different entity using a different key the
>> +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.
>>
>> -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
>> +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. Those SEV command can be issued via KVM_MEMORY_ENCRYPT_OP
>> +encrypted guest. These SEV commands can be issued via KVM_MEMORY_ENCRYPT_OP
>> ioctls.
>>
>> 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,
>> +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 the
>> +images and provide a measurement than can be used as an attestation of a
>> successful launch.
>>
>> LAUNCH_START is called first to create a cryptographic launch context within
>> -the firmware. To create this context, guest owner must provides guest policy,
>> +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 binary blob and must be passed as-is to the SEV firmware.
>> +should be treated as a 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
>> +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 running SEV guest.
>> +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)
>> @@ -40,31 +40,30 @@ The guest policy can be provided via the 'policy' property (see below)
>> # ${QEMU} \
>> sev-guest,id=sev0,policy=0x1...\
>>
>> -Guest owners provided DH certificate and session parameters will be used to
>> +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 'dh-cert-file' and
>> -'session-file' property (see below
>> +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=<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
>> -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_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_FINISH command finalizes the guest launch and destroy's the cryptographic
>> +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
>> @@ -78,10 +77,10 @@ To launch a SEV guest
>>
>> Debugging
>> -----------
>> -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. This is not supported in QEMU yet.
>> +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
>> -----------------
>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation
2021-06-03 8:29 ` Laszlo Ersek
@ 2021-06-03 19:54 ` Eduardo Habkost
0 siblings, 0 replies; 10+ messages in thread
From: Eduardo Habkost @ 2021-06-03 19:54 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Tom Lendacky, Pavel Hrdina, Daniel P . Berrange,
Michal Privoznik, qemu-devel, Dr. David Alan Gilbert,
Brijesh Singh, Paolo Bonzini
On Thu, Jun 03, 2021 at 10:29:35AM +0200, Laszlo Ersek wrote:
> On 06/02/21 21:19, Tom Lendacky wrote:
> > Just a quick ping on this series...
>
> Right, I'm unsure who is supposed to merge this... Do you remember who
> usually merges the SEV-related patch series (plural)?
I'm queueing this series by now, but we truly need somebody to
volunteer as maintainer of the SEV code.
--
Eduardo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation
2021-04-23 20:08 [PATCH v2 1/3] doc: Fix some mistakes in the SEV documentation Tom Lendacky
` (3 preceding siblings ...)
2021-06-02 19:19 ` Tom Lendacky
@ 2021-06-02 20:07 ` Connor Kuehl
4 siblings, 0 replies; 10+ messages in thread
From: Connor Kuehl @ 2021-06-02 20:07 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel
Cc: Pavel Hrdina, Daniel P . Berrange, Eduardo Habkost,
Michal Privoznik, Dr. David Alan Gilbert, Paolo Bonzini,
Brijesh Singh, Laszlo Ersek
On 4/23/21 3:08 PM, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> Fix some spelling and grammar mistakes in the amd-memory-encryption.txt
> file. No new information added.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
For the series:
Reviewed-by: Connor Kuehl <ckuehl@redhat.com>
^ permalink raw reply [flat|nested] 10+ messages in thread