* [PATCH v4 0/6] Qemu SEV-ES guest support
@ 2020-09-25 19:03 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Marcel Apfelbaum, Paolo Bonzini, Dr. David Alan Gilbert,
Eduardo Habkost, Richard Henderson, Connor Kuehl, Brijesh Singh,
Jiri Slaby, Marcelo Tosatti, Michael S. Tsirkin
From: Tom Lendacky <thomas.lendacky@amd.com>
This patch series provides support for launching an SEV-ES guest.
Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
SEV support to protect the guest register state from the hypervisor. See
"AMD64 Architecture Programmer's Manual Volume 2: System Programming",
section "15.35 Encrypted State (SEV-ES)" [1].
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. The notification is performed using a new exception, the VMM
Communication exception (#VC). The information is shared through the
Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
The GHCB format and the protocol for using it is documented in "SEV-ES
Guest-Hypervisor Communication Block Standardization" [2].
The main areas of the Qemu code that are updated to support SEV-ES are
around the SEV guest launch process and AP booting in order to support
booting multiple vCPUs.
There are no new command line switches required. Instead, the desire for
SEV-ES is presented using the SEV policy object. Bit 2 of the SEV policy
object indicates that SEV-ES is required.
The SEV launch process is updated in two ways. The first is that a the
KVM_SEV_ES_INIT ioctl is used to initialize the guest instead of the
standard KVM_SEV_INIT ioctl. The second is that before the SEV launch
measurement is calculated, the LAUNCH_UPDATE_VMSA SEV API is invoked for
each vCPU that Qemu has created. Once the LAUNCH_UPDATE_VMSA API has been
invoked, no direct changes to the guest register state can be made.
AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
is typically used to boot the APs. However, the hypervisor is not allowed
to update the guest registers. For the APs, the reset vector must be known
in advance. An OVMF method to provide a known reset vector address exists
by providing an SEV information block, identified by UUID, near the end of
the firmware [3]. OVMF will program the jump to the actual reset vector in
this area of memory. Since the memory location is known in advance, an AP
can be created with the known reset vector address as its starting CS:IP.
The GHCB document [2] talks about how SMP booting under SEV-ES is
performed. SEV-ES also requires the use of the in-kernel irqchip support
in order to minimize the changes required to Qemu to support AP booting.
[1] https://www.amd.com/system/files/TechDocs/24593.pdf
[2] https://developer.amd.com/wp-content/resources/56421.pdf
[3] 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector")
https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847
---
These patches are based on commit:
d0ed6a69d3 ("Update version for v5.1.0 release")
(I tried basing on the latest Qemu commit, but I was having build issues
that level)
A version of the tree can be found at:
https://github.com/AMDESE/qemu/tree/sev-es-v12
Changes since v3:
- Use the QemuUUID structure for GUID definitions
- Use SEV-ES policy bit definition from target/i386/sev_i386.h
- Update SMM support to a per-VM check in order to check SMM capability
at the VM level since SEV-ES guests don't currently support SMM
- Make the CPU resettable check an arch-specific check
Changes since v2:
- Add in-kernel irqchip requirement for SEV-ES guests
Changes since v1:
- Fixed checkpatch.pl errors/warnings
Tom Lendacky (6):
sev/i386: Add initial support for SEV-ES
sev/i386: Require in-kernel irqchip support for SEV-ES guests
sev/i386: Allow AP booting under SEV-ES
sev/i386: Don't allow a system reset under an SEV-ES guest
kvm/i386: Use a per-VM check for SMM capability
sev/i386: Enable an SEV-ES guest based on SEV policy
accel/kvm/kvm-all.c | 69 ++++++++++++++++++++++++
accel/stubs/kvm-stub.c | 5 ++
hw/i386/pc_sysfw.c | 10 +++-
include/sysemu/cpus.h | 2 +
include/sysemu/hw_accel.h | 5 ++
include/sysemu/kvm.h | 26 +++++++++
include/sysemu/sev.h | 3 ++
softmmu/cpus.c | 5 ++
softmmu/vl.c | 5 +-
target/arm/kvm.c | 5 ++
target/i386/cpu.c | 1 +
target/i386/kvm.c | 10 +++-
target/i386/sev-stub.c | 5 ++
target/i386/sev.c | 109 +++++++++++++++++++++++++++++++++++++-
target/i386/sev_i386.h | 1 +
target/mips/kvm.c | 5 ++
target/ppc/kvm.c | 5 ++
target/s390x/kvm.c | 5 ++
18 files changed, 271 insertions(+), 5 deletions(-)
--
2.28.0
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v4 0/6] Qemu SEV-ES guest support
@ 2020-09-25 19:03 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Paolo Bonzini,
Jiri Slaby, Richard Henderson
From: Tom Lendacky <thomas.lendacky@amd.com>
This patch series provides support for launching an SEV-ES guest.
Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
SEV support to protect the guest register state from the hypervisor. See
"AMD64 Architecture Programmer's Manual Volume 2: System Programming",
section "15.35 Encrypted State (SEV-ES)" [1].
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. The notification is performed using a new exception, the VMM
Communication exception (#VC). The information is shared through the
Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
The GHCB format and the protocol for using it is documented in "SEV-ES
Guest-Hypervisor Communication Block Standardization" [2].
The main areas of the Qemu code that are updated to support SEV-ES are
around the SEV guest launch process and AP booting in order to support
booting multiple vCPUs.
There are no new command line switches required. Instead, the desire for
SEV-ES is presented using the SEV policy object. Bit 2 of the SEV policy
object indicates that SEV-ES is required.
The SEV launch process is updated in two ways. The first is that a the
KVM_SEV_ES_INIT ioctl is used to initialize the guest instead of the
standard KVM_SEV_INIT ioctl. The second is that before the SEV launch
measurement is calculated, the LAUNCH_UPDATE_VMSA SEV API is invoked for
each vCPU that Qemu has created. Once the LAUNCH_UPDATE_VMSA API has been
invoked, no direct changes to the guest register state can be made.
AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
is typically used to boot the APs. However, the hypervisor is not allowed
to update the guest registers. For the APs, the reset vector must be known
in advance. An OVMF method to provide a known reset vector address exists
by providing an SEV information block, identified by UUID, near the end of
the firmware [3]. OVMF will program the jump to the actual reset vector in
this area of memory. Since the memory location is known in advance, an AP
can be created with the known reset vector address as its starting CS:IP.
The GHCB document [2] talks about how SMP booting under SEV-ES is
performed. SEV-ES also requires the use of the in-kernel irqchip support
in order to minimize the changes required to Qemu to support AP booting.
[1] https://www.amd.com/system/files/TechDocs/24593.pdf
[2] https://developer.amd.com/wp-content/resources/56421.pdf
[3] 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector")
https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847
---
These patches are based on commit:
d0ed6a69d3 ("Update version for v5.1.0 release")
(I tried basing on the latest Qemu commit, but I was having build issues
that level)
A version of the tree can be found at:
https://github.com/AMDESE/qemu/tree/sev-es-v12
Changes since v3:
- Use the QemuUUID structure for GUID definitions
- Use SEV-ES policy bit definition from target/i386/sev_i386.h
- Update SMM support to a per-VM check in order to check SMM capability
at the VM level since SEV-ES guests don't currently support SMM
- Make the CPU resettable check an arch-specific check
Changes since v2:
- Add in-kernel irqchip requirement for SEV-ES guests
Changes since v1:
- Fixed checkpatch.pl errors/warnings
Tom Lendacky (6):
sev/i386: Add initial support for SEV-ES
sev/i386: Require in-kernel irqchip support for SEV-ES guests
sev/i386: Allow AP booting under SEV-ES
sev/i386: Don't allow a system reset under an SEV-ES guest
kvm/i386: Use a per-VM check for SMM capability
sev/i386: Enable an SEV-ES guest based on SEV policy
accel/kvm/kvm-all.c | 69 ++++++++++++++++++++++++
accel/stubs/kvm-stub.c | 5 ++
hw/i386/pc_sysfw.c | 10 +++-
include/sysemu/cpus.h | 2 +
include/sysemu/hw_accel.h | 5 ++
include/sysemu/kvm.h | 26 +++++++++
include/sysemu/sev.h | 3 ++
softmmu/cpus.c | 5 ++
softmmu/vl.c | 5 +-
target/arm/kvm.c | 5 ++
target/i386/cpu.c | 1 +
target/i386/kvm.c | 10 +++-
target/i386/sev-stub.c | 5 ++
target/i386/sev.c | 109 +++++++++++++++++++++++++++++++++++++-
target/i386/sev_i386.h | 1 +
target/mips/kvm.c | 5 ++
target/ppc/kvm.c | 5 ++
target/s390x/kvm.c | 5 ++
18 files changed, 271 insertions(+), 5 deletions(-)
--
2.28.0
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v4 1/6] sev/i386: Add initial support for SEV-ES
2020-09-25 19:03 ` Tom Lendacky
@ 2020-09-25 19:03 ` Tom Lendacky
-1 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Marcel Apfelbaum, Paolo Bonzini, Dr. David Alan Gilbert,
Eduardo Habkost, Richard Henderson, Connor Kuehl, Brijesh Singh,
Jiri Slaby, Marcelo Tosatti, Michael S. Tsirkin
From: Tom Lendacky <thomas.lendacky@amd.com>
Provide initial support for SEV-ES. This includes creating a function to
indicate the guest is an SEV-ES guest (which will return false until all
support is in place), performing the proper SEV initialization and
ensuring that the guest CPU state is measured as part of the launch.
Co-developed-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
target/i386/cpu.c | 1 +
target/i386/sev-stub.c | 5 +++++
target/i386/sev.c | 44 ++++++++++++++++++++++++++++++++++++++++--
target/i386/sev_i386.h | 1 +
4 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 3ffd877dd5..ca0e17ed07 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5940,6 +5940,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
break;
case 0x8000001F:
*eax = sev_enabled() ? 0x2 : 0;
+ *eax |= sev_es_enabled() ? 0x8 : 0;
*ebx = sev_get_cbit_position();
*ebx |= sev_get_reduced_phys_bits() << 6;
*ecx = 0;
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
index 88e3f39a1e..040ac90563 100644
--- a/target/i386/sev-stub.c
+++ b/target/i386/sev-stub.c
@@ -49,3 +49,8 @@ SevCapability *sev_get_capabilities(Error **errp)
error_setg(errp, "SEV is not available in this QEMU");
return NULL;
}
+
+bool sev_es_enabled(void)
+{
+ return false;
+}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 93c4d60b82..af6b88691f 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -358,6 +358,12 @@ sev_enabled(void)
return !!sev_guest;
}
+bool
+sev_es_enabled(void)
+{
+ return false;
+}
+
uint64_t
sev_get_me_mask(void)
{
@@ -578,6 +584,20 @@ sev_launch_update_data(SevGuestState *sev, uint8_t *addr, uint64_t len)
return ret;
}
+static int
+sev_launch_update_vmsa(SevGuestState *sev)
+{
+ int ret, fw_error;
+
+ ret = sev_ioctl(sev->sev_fd, KVM_SEV_LAUNCH_UPDATE_VMSA, NULL, &fw_error);
+ if (ret) {
+ error_report("%s: LAUNCH_UPDATE_VMSA ret=%d fw_error=%d '%s'",
+ __func__, ret, fw_error, fw_error_to_str(fw_error));
+ }
+
+ return ret;
+}
+
static void
sev_launch_get_measure(Notifier *notifier, void *unused)
{
@@ -590,6 +610,14 @@ sev_launch_get_measure(Notifier *notifier, void *unused)
return;
}
+ if (sev_es_enabled()) {
+ /* measure all the VM save areas before getting launch_measure */
+ ret = sev_launch_update_vmsa(sev);
+ if (ret) {
+ exit(1);
+ }
+ }
+
measurement = g_new0(struct kvm_sev_launch_measure, 1);
/* query the measurement blob length */
@@ -684,7 +712,7 @@ sev_guest_init(const char *id)
{
SevGuestState *sev;
char *devname;
- int ret, fw_error;
+ int ret, fw_error, cmd;
uint32_t ebx;
uint32_t host_cbitpos;
struct sev_user_data_status status = {};
@@ -745,8 +773,20 @@ sev_guest_init(const char *id)
sev->api_major = status.api_major;
sev->api_minor = status.api_minor;
+ if (sev_es_enabled()) {
+ if (!(status.flags & SEV_STATUS_FLAGS_CONFIG_ES)) {
+ error_report("%s: guest policy requires SEV-ES, but "
+ "host SEV-ES support unavailable",
+ __func__);
+ goto err;
+ }
+ cmd = KVM_SEV_ES_INIT;
+ } else {
+ cmd = KVM_SEV_INIT;
+ }
+
trace_kvm_sev_init();
- ret = sev_ioctl(sev->sev_fd, KVM_SEV_INIT, NULL, &fw_error);
+ ret = sev_ioctl(sev->sev_fd, cmd, NULL, &fw_error);
if (ret) {
error_report("%s: failed to initialize ret=%d fw_error=%d '%s'",
__func__, ret, fw_error, fw_error_to_str(fw_error));
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
index 4db6960f60..4f9a5e9b21 100644
--- a/target/i386/sev_i386.h
+++ b/target/i386/sev_i386.h
@@ -29,6 +29,7 @@
#define SEV_POLICY_SEV 0x20
extern bool sev_enabled(void);
+extern bool sev_es_enabled(void);
extern uint64_t sev_get_me_mask(void);
extern SevInfo *sev_get_info(void);
extern uint32_t sev_get_cbit_position(void);
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 1/6] sev/i386: Add initial support for SEV-ES
@ 2020-09-25 19:03 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Paolo Bonzini,
Jiri Slaby, Richard Henderson
From: Tom Lendacky <thomas.lendacky@amd.com>
Provide initial support for SEV-ES. This includes creating a function to
indicate the guest is an SEV-ES guest (which will return false until all
support is in place), performing the proper SEV initialization and
ensuring that the guest CPU state is measured as part of the launch.
Co-developed-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
target/i386/cpu.c | 1 +
target/i386/sev-stub.c | 5 +++++
target/i386/sev.c | 44 ++++++++++++++++++++++++++++++++++++++++--
target/i386/sev_i386.h | 1 +
4 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 3ffd877dd5..ca0e17ed07 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5940,6 +5940,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
break;
case 0x8000001F:
*eax = sev_enabled() ? 0x2 : 0;
+ *eax |= sev_es_enabled() ? 0x8 : 0;
*ebx = sev_get_cbit_position();
*ebx |= sev_get_reduced_phys_bits() << 6;
*ecx = 0;
diff --git a/target/i386/sev-stub.c b/target/i386/sev-stub.c
index 88e3f39a1e..040ac90563 100644
--- a/target/i386/sev-stub.c
+++ b/target/i386/sev-stub.c
@@ -49,3 +49,8 @@ SevCapability *sev_get_capabilities(Error **errp)
error_setg(errp, "SEV is not available in this QEMU");
return NULL;
}
+
+bool sev_es_enabled(void)
+{
+ return false;
+}
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 93c4d60b82..af6b88691f 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -358,6 +358,12 @@ sev_enabled(void)
return !!sev_guest;
}
+bool
+sev_es_enabled(void)
+{
+ return false;
+}
+
uint64_t
sev_get_me_mask(void)
{
@@ -578,6 +584,20 @@ sev_launch_update_data(SevGuestState *sev, uint8_t *addr, uint64_t len)
return ret;
}
+static int
+sev_launch_update_vmsa(SevGuestState *sev)
+{
+ int ret, fw_error;
+
+ ret = sev_ioctl(sev->sev_fd, KVM_SEV_LAUNCH_UPDATE_VMSA, NULL, &fw_error);
+ if (ret) {
+ error_report("%s: LAUNCH_UPDATE_VMSA ret=%d fw_error=%d '%s'",
+ __func__, ret, fw_error, fw_error_to_str(fw_error));
+ }
+
+ return ret;
+}
+
static void
sev_launch_get_measure(Notifier *notifier, void *unused)
{
@@ -590,6 +610,14 @@ sev_launch_get_measure(Notifier *notifier, void *unused)
return;
}
+ if (sev_es_enabled()) {
+ /* measure all the VM save areas before getting launch_measure */
+ ret = sev_launch_update_vmsa(sev);
+ if (ret) {
+ exit(1);
+ }
+ }
+
measurement = g_new0(struct kvm_sev_launch_measure, 1);
/* query the measurement blob length */
@@ -684,7 +712,7 @@ sev_guest_init(const char *id)
{
SevGuestState *sev;
char *devname;
- int ret, fw_error;
+ int ret, fw_error, cmd;
uint32_t ebx;
uint32_t host_cbitpos;
struct sev_user_data_status status = {};
@@ -745,8 +773,20 @@ sev_guest_init(const char *id)
sev->api_major = status.api_major;
sev->api_minor = status.api_minor;
+ if (sev_es_enabled()) {
+ if (!(status.flags & SEV_STATUS_FLAGS_CONFIG_ES)) {
+ error_report("%s: guest policy requires SEV-ES, but "
+ "host SEV-ES support unavailable",
+ __func__);
+ goto err;
+ }
+ cmd = KVM_SEV_ES_INIT;
+ } else {
+ cmd = KVM_SEV_INIT;
+ }
+
trace_kvm_sev_init();
- ret = sev_ioctl(sev->sev_fd, KVM_SEV_INIT, NULL, &fw_error);
+ ret = sev_ioctl(sev->sev_fd, cmd, NULL, &fw_error);
if (ret) {
error_report("%s: failed to initialize ret=%d fw_error=%d '%s'",
__func__, ret, fw_error, fw_error_to_str(fw_error));
diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
index 4db6960f60..4f9a5e9b21 100644
--- a/target/i386/sev_i386.h
+++ b/target/i386/sev_i386.h
@@ -29,6 +29,7 @@
#define SEV_POLICY_SEV 0x20
extern bool sev_enabled(void);
+extern bool sev_es_enabled(void);
extern uint64_t sev_get_me_mask(void);
extern SevInfo *sev_get_info(void);
extern uint32_t sev_get_cbit_position(void);
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 2/6] sev/i386: Require in-kernel irqchip support for SEV-ES guests
2020-09-25 19:03 ` Tom Lendacky
@ 2020-09-25 19:03 ` Tom Lendacky
-1 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Marcel Apfelbaum, Paolo Bonzini, Dr. David Alan Gilbert,
Eduardo Habkost, Richard Henderson, Connor Kuehl, Brijesh Singh,
Jiri Slaby, Marcelo Tosatti, Michael S. Tsirkin
From: Tom Lendacky <thomas.lendacky@amd.com>
In prep for AP booting, require the use of in-kernel irqchip support. This
lessens the Qemu support burden required to boot APs.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
target/i386/sev.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index af6b88691f..0d4bd3cd75 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -774,6 +774,12 @@ sev_guest_init(const char *id)
sev->api_minor = status.api_minor;
if (sev_es_enabled()) {
+ if (!kvm_kernel_irqchip_allowed()) {
+ error_report("%s: SEV-ES guests require in-kernel irqchip support",
+ __func__);
+ goto err;
+ }
+
if (!(status.flags & SEV_STATUS_FLAGS_CONFIG_ES)) {
error_report("%s: guest policy requires SEV-ES, but "
"host SEV-ES support unavailable",
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 2/6] sev/i386: Require in-kernel irqchip support for SEV-ES guests
@ 2020-09-25 19:03 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Paolo Bonzini,
Jiri Slaby, Richard Henderson
From: Tom Lendacky <thomas.lendacky@amd.com>
In prep for AP booting, require the use of in-kernel irqchip support. This
lessens the Qemu support burden required to boot APs.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
target/i386/sev.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index af6b88691f..0d4bd3cd75 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -774,6 +774,12 @@ sev_guest_init(const char *id)
sev->api_minor = status.api_minor;
if (sev_es_enabled()) {
+ if (!kvm_kernel_irqchip_allowed()) {
+ error_report("%s: SEV-ES guests require in-kernel irqchip support",
+ __func__);
+ goto err;
+ }
+
if (!(status.flags & SEV_STATUS_FLAGS_CONFIG_ES)) {
error_report("%s: guest policy requires SEV-ES, but "
"host SEV-ES support unavailable",
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 3/6] sev/i386: Allow AP booting under SEV-ES
2020-09-25 19:03 ` Tom Lendacky
@ 2020-09-25 19:03 ` Tom Lendacky
-1 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Marcel Apfelbaum, Paolo Bonzini, Dr. David Alan Gilbert,
Eduardo Habkost, Richard Henderson, Connor Kuehl, Brijesh Singh,
Jiri Slaby, Marcelo Tosatti, Michael S. Tsirkin
From: Tom Lendacky <thomas.lendacky@amd.com>
When SEV-ES is enabled, it is not possible modify the guests register
state after it has been initially created, encrypted and measured.
Normally, an INIT-SIPI-SIPI request is used to boot the AP. However, the
hypervisor cannot emulate this because it cannot update the AP register
state. For the very first boot by an AP, the reset vector CS segment
value and the EIP value must be programmed before the register has been
encrypted and measured.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
accel/kvm/kvm-all.c | 64 ++++++++++++++++++++++++++++++++++++++++++
accel/stubs/kvm-stub.c | 5 ++++
hw/i386/pc_sysfw.c | 10 ++++++-
include/sysemu/kvm.h | 16 +++++++++++
include/sysemu/sev.h | 3 ++
target/i386/kvm.c | 2 ++
target/i386/sev.c | 59 ++++++++++++++++++++++++++++++++++++++
7 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index ad8b315b35..08b66642dd 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -39,6 +39,7 @@
#include "qemu/main-loop.h"
#include "trace.h"
#include "hw/irq.h"
+#include "sysemu/kvm.h"
#include "sysemu/sev.h"
#include "qapi/visitor.h"
#include "qapi/qapi-types-common.h"
@@ -120,6 +121,12 @@ struct KVMState
/* memory encryption */
void *memcrypt_handle;
int (*memcrypt_encrypt_data)(void *handle, uint8_t *ptr, uint64_t len);
+ int (*memcrypt_save_reset_vector)(void *handle, void *flash_ptr,
+ uint64_t flash_size, uint32_t *addr);
+
+ uint32_t reset_cs;
+ uint32_t reset_ip;
+ bool reset_data_valid;
/* For "info mtree -f" to tell if an MR is registered in KVM */
int nr_as;
@@ -239,6 +246,62 @@ int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
return 1;
}
+void kvm_memcrypt_set_reset_vector(CPUState *cpu)
+{
+ X86CPU *x86;
+ CPUX86State *env;
+
+ /* Only update if we have valid reset information */
+ if (!kvm_state->reset_data_valid) {
+ return;
+ }
+
+ /* Do not update the BSP reset state */
+ if (cpu->cpu_index == 0) {
+ return;
+ }
+
+ x86 = X86_CPU(cpu);
+ env = &x86->env;
+
+ cpu_x86_load_seg_cache(env, R_CS, 0xf000, kvm_state->reset_cs, 0xffff,
+ DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK |
+ DESC_R_MASK | DESC_A_MASK);
+
+ env->eip = kvm_state->reset_ip;
+}
+
+int kvm_memcrypt_save_reset_vector(void *flash_ptr, uint64_t flash_size)
+{
+ CPUState *cpu;
+ uint32_t addr;
+ int ret;
+
+ if (kvm_memcrypt_enabled() &&
+ kvm_state->memcrypt_save_reset_vector) {
+
+ addr = 0;
+ ret = kvm_state->memcrypt_save_reset_vector(kvm_state->memcrypt_handle,
+ flash_ptr, flash_size,
+ &addr);
+ if (ret) {
+ return ret;
+ }
+
+ if (addr) {
+ kvm_state->reset_cs = addr & 0xffff0000;
+ kvm_state->reset_ip = addr & 0x0000ffff;
+ kvm_state->reset_data_valid = true;
+
+ CPU_FOREACH(cpu) {
+ kvm_memcrypt_set_reset_vector(cpu);
+ }
+ }
+ }
+
+ return 0;
+}
+
/* Called with KVMMemoryListener.slots_lock held */
static KVMSlot *kvm_get_free_slot(KVMMemoryListener *kml)
{
@@ -2193,6 +2256,7 @@ static int kvm_init(MachineState *ms)
}
kvm_state->memcrypt_encrypt_data = sev_encrypt_data;
+ kvm_state->memcrypt_save_reset_vector = sev_es_save_reset_vector;
}
ret = kvm_arch_init(ms, s);
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 82f118d2df..3aece9b513 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -114,6 +114,11 @@ int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
return 1;
}
+int kvm_memcrypt_save_reset_vector(void *flash_ptr, uint64_t flash_size)
+{
+ return -ENOSYS;
+}
+
#ifndef CONFIG_USER_ONLY
int kvm_irqchip_add_msi_route(KVMState *s, int vector, PCIDevice *dev)
{
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index b6c0822fe3..321ff94261 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -156,7 +156,8 @@ static void pc_system_flash_map(PCMachineState *pcms,
PFlashCFI01 *system_flash;
MemoryRegion *flash_mem;
void *flash_ptr;
- int ret, flash_size;
+ uint64_t flash_size;
+ int ret;
assert(PC_MACHINE_GET_CLASS(pcms)->pci_enabled);
@@ -204,6 +205,13 @@ static void pc_system_flash_map(PCMachineState *pcms,
if (kvm_memcrypt_enabled()) {
flash_ptr = memory_region_get_ram_ptr(flash_mem);
flash_size = memory_region_size(flash_mem);
+
+ ret = kvm_memcrypt_save_reset_vector(flash_ptr, flash_size);
+ if (ret) {
+ error_report("failed to locate and/or save reset vector");
+ exit(1);
+ }
+
ret = kvm_memcrypt_encrypt_data(flash_ptr, flash_size);
if (ret) {
error_report("failed to encrypt pflash rom");
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 5bbea53883..b7ff481d61 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -254,6 +254,22 @@ bool kvm_memcrypt_enabled(void);
*/
int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len);
+/**
+ * kvm_memcrypt_set_reset_vector - sets the CS/IP value for the AP if SEV-ES
+ * is active.
+ */
+void kvm_memcrypt_set_reset_vector(CPUState *cpu);
+
+/**
+ * kvm_memcrypt_save_reset_vector - locates and saves the reset vector to be
+ * used as the initial CS/IP value for APs
+ * if SEV-ES is active.
+ *
+ * Return: 1 SEV-ES is active and failed to locate a valid reset vector
+ * 0 SEV-ES is not active or successfully located and saved the
+ * reset vector address
+ */
+int kvm_memcrypt_save_reset_vector(void *flash_prt, uint64_t flash_size);
#ifdef NEED_CPU_H
#include "cpu.h"
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
index 98c1ec8d38..5198e5a621 100644
--- a/include/sysemu/sev.h
+++ b/include/sysemu/sev.h
@@ -18,4 +18,7 @@
void *sev_guest_init(const char *id);
int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len);
+int sev_es_save_reset_vector(void *handle, void *flash_ptr,
+ uint64_t flash_size, uint32_t *addr);
+
#endif
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 9efb07e7c8..7c2a3a123b 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1913,6 +1913,8 @@ void kvm_arch_reset_vcpu(X86CPU *cpu)
}
/* enabled by default */
env->poll_control_msr = 1;
+
+ kvm_memcrypt_set_reset_vector(CPU(cpu));
}
void kvm_arch_do_init_vcpu(X86CPU *cpu)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 0d4bd3cd75..9c081173db 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -22,6 +22,7 @@
#include "qom/object_interfaces.h"
#include "qemu/base64.h"
#include "qemu/module.h"
+#include "qemu/uuid.h"
#include "sysemu/kvm.h"
#include "sev_i386.h"
#include "sysemu/sysemu.h"
@@ -69,6 +70,21 @@ struct SevGuestState {
#define DEFAULT_GUEST_POLICY 0x1 /* disable debug */
#define DEFAULT_SEV_DEVICE "/dev/sev"
+/* SEV Information Block GUID = 00f771de-1a7e-4fcb-890e-68c77e2fb44e */
+static const QemuUUID sev_info_block_guid_le = {
+ .data = UUID_LE(0x00f771de, 0x1a7e, 0x4fcb,
+ 0x89, 0x0e, 0x68, 0xc7, 0x7e, 0x2f, 0xb4, 0x4e),
+};
+
+typedef struct __attribute__((__packed__)) SevInfoBlock {
+ /* SEV-ES Reset Vector Address */
+ uint32_t reset_addr;
+
+ /* SEV Information Block size and GUID */
+ uint16_t size;
+ QemuUUID guid;
+} SevInfoBlock;
+
static SevGuestState *sev_guest;
static Error *sev_mig_blocker;
@@ -831,6 +847,49 @@ sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
return 0;
}
+int
+sev_es_save_reset_vector(void *handle, void *flash_ptr, uint64_t flash_size,
+ uint32_t *addr)
+{
+ QemuUUID *info_guid;
+ SevInfoBlock *info;
+
+ assert(handle);
+
+ /*
+ * Initialize the address to zero. An address of zero with a successful
+ * return code indicates that SEV-ES is not active.
+ */
+ *addr = 0;
+ if (!sev_es_enabled()) {
+ return 0;
+ }
+
+ /*
+ * Extract the AP reset vector for SEV-ES guests by locating the SEV GUID.
+ * The SEV GUID is located 32 bytes from the end of the flash. Use this
+ * address to base the SEV information block.
+ *
+ * Because SevInfoBlock is a packed structure, operate on the GUID
+ * directly to avoid compiler warnings/errors.
+ */
+ info_guid = flash_ptr + flash_size - 0x20 - sizeof(*info_guid);
+ if (!qemu_uuid_is_equal(info_guid, &sev_info_block_guid_le)) {
+ error_report("SEV information block not found in pflash rom");
+ return 1;
+ }
+
+ info = flash_ptr + flash_size - 0x20 - sizeof(*info);
+ if (!info->reset_addr) {
+ error_report("SEV-ES reset address is zero");
+ return 1;
+ }
+
+ *addr = info->reset_addr;
+
+ return 0;
+}
+
static void
sev_register_types(void)
{
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 3/6] sev/i386: Allow AP booting under SEV-ES
@ 2020-09-25 19:03 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Paolo Bonzini,
Jiri Slaby, Richard Henderson
From: Tom Lendacky <thomas.lendacky@amd.com>
When SEV-ES is enabled, it is not possible modify the guests register
state after it has been initially created, encrypted and measured.
Normally, an INIT-SIPI-SIPI request is used to boot the AP. However, the
hypervisor cannot emulate this because it cannot update the AP register
state. For the very first boot by an AP, the reset vector CS segment
value and the EIP value must be programmed before the register has been
encrypted and measured.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
accel/kvm/kvm-all.c | 64 ++++++++++++++++++++++++++++++++++++++++++
accel/stubs/kvm-stub.c | 5 ++++
hw/i386/pc_sysfw.c | 10 ++++++-
include/sysemu/kvm.h | 16 +++++++++++
include/sysemu/sev.h | 3 ++
target/i386/kvm.c | 2 ++
target/i386/sev.c | 59 ++++++++++++++++++++++++++++++++++++++
7 files changed, 158 insertions(+), 1 deletion(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index ad8b315b35..08b66642dd 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -39,6 +39,7 @@
#include "qemu/main-loop.h"
#include "trace.h"
#include "hw/irq.h"
+#include "sysemu/kvm.h"
#include "sysemu/sev.h"
#include "qapi/visitor.h"
#include "qapi/qapi-types-common.h"
@@ -120,6 +121,12 @@ struct KVMState
/* memory encryption */
void *memcrypt_handle;
int (*memcrypt_encrypt_data)(void *handle, uint8_t *ptr, uint64_t len);
+ int (*memcrypt_save_reset_vector)(void *handle, void *flash_ptr,
+ uint64_t flash_size, uint32_t *addr);
+
+ uint32_t reset_cs;
+ uint32_t reset_ip;
+ bool reset_data_valid;
/* For "info mtree -f" to tell if an MR is registered in KVM */
int nr_as;
@@ -239,6 +246,62 @@ int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
return 1;
}
+void kvm_memcrypt_set_reset_vector(CPUState *cpu)
+{
+ X86CPU *x86;
+ CPUX86State *env;
+
+ /* Only update if we have valid reset information */
+ if (!kvm_state->reset_data_valid) {
+ return;
+ }
+
+ /* Do not update the BSP reset state */
+ if (cpu->cpu_index == 0) {
+ return;
+ }
+
+ x86 = X86_CPU(cpu);
+ env = &x86->env;
+
+ cpu_x86_load_seg_cache(env, R_CS, 0xf000, kvm_state->reset_cs, 0xffff,
+ DESC_P_MASK | DESC_S_MASK | DESC_CS_MASK |
+ DESC_R_MASK | DESC_A_MASK);
+
+ env->eip = kvm_state->reset_ip;
+}
+
+int kvm_memcrypt_save_reset_vector(void *flash_ptr, uint64_t flash_size)
+{
+ CPUState *cpu;
+ uint32_t addr;
+ int ret;
+
+ if (kvm_memcrypt_enabled() &&
+ kvm_state->memcrypt_save_reset_vector) {
+
+ addr = 0;
+ ret = kvm_state->memcrypt_save_reset_vector(kvm_state->memcrypt_handle,
+ flash_ptr, flash_size,
+ &addr);
+ if (ret) {
+ return ret;
+ }
+
+ if (addr) {
+ kvm_state->reset_cs = addr & 0xffff0000;
+ kvm_state->reset_ip = addr & 0x0000ffff;
+ kvm_state->reset_data_valid = true;
+
+ CPU_FOREACH(cpu) {
+ kvm_memcrypt_set_reset_vector(cpu);
+ }
+ }
+ }
+
+ return 0;
+}
+
/* Called with KVMMemoryListener.slots_lock held */
static KVMSlot *kvm_get_free_slot(KVMMemoryListener *kml)
{
@@ -2193,6 +2256,7 @@ static int kvm_init(MachineState *ms)
}
kvm_state->memcrypt_encrypt_data = sev_encrypt_data;
+ kvm_state->memcrypt_save_reset_vector = sev_es_save_reset_vector;
}
ret = kvm_arch_init(ms, s);
diff --git a/accel/stubs/kvm-stub.c b/accel/stubs/kvm-stub.c
index 82f118d2df..3aece9b513 100644
--- a/accel/stubs/kvm-stub.c
+++ b/accel/stubs/kvm-stub.c
@@ -114,6 +114,11 @@ int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len)
return 1;
}
+int kvm_memcrypt_save_reset_vector(void *flash_ptr, uint64_t flash_size)
+{
+ return -ENOSYS;
+}
+
#ifndef CONFIG_USER_ONLY
int kvm_irqchip_add_msi_route(KVMState *s, int vector, PCIDevice *dev)
{
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index b6c0822fe3..321ff94261 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -156,7 +156,8 @@ static void pc_system_flash_map(PCMachineState *pcms,
PFlashCFI01 *system_flash;
MemoryRegion *flash_mem;
void *flash_ptr;
- int ret, flash_size;
+ uint64_t flash_size;
+ int ret;
assert(PC_MACHINE_GET_CLASS(pcms)->pci_enabled);
@@ -204,6 +205,13 @@ static void pc_system_flash_map(PCMachineState *pcms,
if (kvm_memcrypt_enabled()) {
flash_ptr = memory_region_get_ram_ptr(flash_mem);
flash_size = memory_region_size(flash_mem);
+
+ ret = kvm_memcrypt_save_reset_vector(flash_ptr, flash_size);
+ if (ret) {
+ error_report("failed to locate and/or save reset vector");
+ exit(1);
+ }
+
ret = kvm_memcrypt_encrypt_data(flash_ptr, flash_size);
if (ret) {
error_report("failed to encrypt pflash rom");
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index 5bbea53883..b7ff481d61 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -254,6 +254,22 @@ bool kvm_memcrypt_enabled(void);
*/
int kvm_memcrypt_encrypt_data(uint8_t *ptr, uint64_t len);
+/**
+ * kvm_memcrypt_set_reset_vector - sets the CS/IP value for the AP if SEV-ES
+ * is active.
+ */
+void kvm_memcrypt_set_reset_vector(CPUState *cpu);
+
+/**
+ * kvm_memcrypt_save_reset_vector - locates and saves the reset vector to be
+ * used as the initial CS/IP value for APs
+ * if SEV-ES is active.
+ *
+ * Return: 1 SEV-ES is active and failed to locate a valid reset vector
+ * 0 SEV-ES is not active or successfully located and saved the
+ * reset vector address
+ */
+int kvm_memcrypt_save_reset_vector(void *flash_prt, uint64_t flash_size);
#ifdef NEED_CPU_H
#include "cpu.h"
diff --git a/include/sysemu/sev.h b/include/sysemu/sev.h
index 98c1ec8d38..5198e5a621 100644
--- a/include/sysemu/sev.h
+++ b/include/sysemu/sev.h
@@ -18,4 +18,7 @@
void *sev_guest_init(const char *id);
int sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len);
+int sev_es_save_reset_vector(void *handle, void *flash_ptr,
+ uint64_t flash_size, uint32_t *addr);
+
#endif
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 9efb07e7c8..7c2a3a123b 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1913,6 +1913,8 @@ void kvm_arch_reset_vcpu(X86CPU *cpu)
}
/* enabled by default */
env->poll_control_msr = 1;
+
+ kvm_memcrypt_set_reset_vector(CPU(cpu));
}
void kvm_arch_do_init_vcpu(X86CPU *cpu)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 0d4bd3cd75..9c081173db 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -22,6 +22,7 @@
#include "qom/object_interfaces.h"
#include "qemu/base64.h"
#include "qemu/module.h"
+#include "qemu/uuid.h"
#include "sysemu/kvm.h"
#include "sev_i386.h"
#include "sysemu/sysemu.h"
@@ -69,6 +70,21 @@ struct SevGuestState {
#define DEFAULT_GUEST_POLICY 0x1 /* disable debug */
#define DEFAULT_SEV_DEVICE "/dev/sev"
+/* SEV Information Block GUID = 00f771de-1a7e-4fcb-890e-68c77e2fb44e */
+static const QemuUUID sev_info_block_guid_le = {
+ .data = UUID_LE(0x00f771de, 0x1a7e, 0x4fcb,
+ 0x89, 0x0e, 0x68, 0xc7, 0x7e, 0x2f, 0xb4, 0x4e),
+};
+
+typedef struct __attribute__((__packed__)) SevInfoBlock {
+ /* SEV-ES Reset Vector Address */
+ uint32_t reset_addr;
+
+ /* SEV Information Block size and GUID */
+ uint16_t size;
+ QemuUUID guid;
+} SevInfoBlock;
+
static SevGuestState *sev_guest;
static Error *sev_mig_blocker;
@@ -831,6 +847,49 @@ sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
return 0;
}
+int
+sev_es_save_reset_vector(void *handle, void *flash_ptr, uint64_t flash_size,
+ uint32_t *addr)
+{
+ QemuUUID *info_guid;
+ SevInfoBlock *info;
+
+ assert(handle);
+
+ /*
+ * Initialize the address to zero. An address of zero with a successful
+ * return code indicates that SEV-ES is not active.
+ */
+ *addr = 0;
+ if (!sev_es_enabled()) {
+ return 0;
+ }
+
+ /*
+ * Extract the AP reset vector for SEV-ES guests by locating the SEV GUID.
+ * The SEV GUID is located 32 bytes from the end of the flash. Use this
+ * address to base the SEV information block.
+ *
+ * Because SevInfoBlock is a packed structure, operate on the GUID
+ * directly to avoid compiler warnings/errors.
+ */
+ info_guid = flash_ptr + flash_size - 0x20 - sizeof(*info_guid);
+ if (!qemu_uuid_is_equal(info_guid, &sev_info_block_guid_le)) {
+ error_report("SEV information block not found in pflash rom");
+ return 1;
+ }
+
+ info = flash_ptr + flash_size - 0x20 - sizeof(*info);
+ if (!info->reset_addr) {
+ error_report("SEV-ES reset address is zero");
+ return 1;
+ }
+
+ *addr = info->reset_addr;
+
+ return 0;
+}
+
static void
sev_register_types(void)
{
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest
2020-09-25 19:03 ` Tom Lendacky
@ 2020-09-25 19:03 ` Tom Lendacky
-1 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Marcel Apfelbaum, Paolo Bonzini, Dr. David Alan Gilbert,
Eduardo Habkost, Richard Henderson, Connor Kuehl, Brijesh Singh,
Jiri Slaby, Marcelo Tosatti, Michael S. Tsirkin, Peter Maydell,
Aurelien Jarno, Jiaxun Yang, Aleksandar Rikalo, David Gibson,
David Hildenbrand
From: Tom Lendacky <thomas.lendacky@amd.com>
An SEV-ES guest does not allow register state to be altered once it has
been measured. When an SEV-ES guest issues a reboot command, Qemu will
reset the vCPU state and resume the guest. This will cause failures under
SEV-ES. Prevent that from occuring by introducing an arch-specific
callback that returns a boolean indicating whether vCPUs are resettable.
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: David Hildenbrand <david@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
accel/kvm/kvm-all.c | 5 +++++
include/sysemu/cpus.h | 2 ++
include/sysemu/hw_accel.h | 5 +++++
include/sysemu/kvm.h | 10 ++++++++++
softmmu/cpus.c | 5 +++++
softmmu/vl.c | 5 ++++-
target/arm/kvm.c | 5 +++++
target/i386/kvm.c | 6 ++++++
target/mips/kvm.c | 5 +++++
target/ppc/kvm.c | 5 +++++
target/s390x/kvm.c | 5 +++++
11 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 08b66642dd..a161fff813 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2388,6 +2388,11 @@ void kvm_flush_coalesced_mmio_buffer(void)
s->coalesced_flush_in_progress = false;
}
+bool kvm_cpu_check_are_resettable(void)
+{
+ return kvm_arch_cpu_check_are_resettable();
+}
+
static void do_kvm_cpu_synchronize_state(CPUState *cpu, run_on_cpu_data arg)
{
if (!cpu->vcpu_dirty) {
diff --git a/include/sysemu/cpus.h b/include/sysemu/cpus.h
index 3c1da6a018..d3e6cdf126 100644
--- a/include/sysemu/cpus.h
+++ b/include/sysemu/cpus.h
@@ -24,6 +24,8 @@ void dump_drift_info(void);
void qemu_cpu_kick_self(void);
void qemu_timer_notify_cb(void *opaque, QEMUClockType type);
+bool cpus_are_resettable(void);
+
void cpu_synchronize_all_states(void);
void cpu_synchronize_all_post_reset(void);
void cpu_synchronize_all_post_init(void);
diff --git a/include/sysemu/hw_accel.h b/include/sysemu/hw_accel.h
index e128f8b06b..6d387226d4 100644
--- a/include/sysemu/hw_accel.h
+++ b/include/sysemu/hw_accel.h
@@ -17,6 +17,11 @@
#include "sysemu/hvf.h"
#include "sysemu/whpx.h"
+static inline bool cpu_check_are_resettable(void)
+{
+ return kvm_enabled() ? kvm_cpu_check_are_resettable() : true;
+}
+
static inline void cpu_synchronize_state(CPUState *cpu)
{
if (kvm_enabled()) {
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index b7ff481d61..51a12c83ed 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -581,4 +581,14 @@ int kvm_get_max_memslots(void);
/* Notify resamplefd for EOI of specific interrupts. */
void kvm_resample_fd_notify(int gsi);
+/**
+ * kvm_cpu_check_are_resettable - return whether CPUs can be reset
+ *
+ * Returns: true: CPUs are resettable
+ * false: CPUs are not resettable
+ */
+bool kvm_cpu_check_are_resettable(void);
+
+bool kvm_arch_cpu_check_are_resettable(void);
+
#endif
diff --git a/softmmu/cpus.c b/softmmu/cpus.c
index e3b98065c9..ee9c46527c 100644
--- a/softmmu/cpus.c
+++ b/softmmu/cpus.c
@@ -927,6 +927,11 @@ void hw_error(const char *fmt, ...)
abort();
}
+bool cpus_are_resettable(void)
+{
+ return cpu_check_are_resettable();
+}
+
void cpu_synchronize_all_states(void)
{
CPUState *cpu;
diff --git a/softmmu/vl.c b/softmmu/vl.c
index f7b103467c..1f54c6b416 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -1475,7 +1475,10 @@ void qemu_system_guest_crashloaded(GuestPanicInformation *info)
void qemu_system_reset_request(ShutdownCause reason)
{
- if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
+ if (!cpus_are_resettable()) {
+ error_report("cpus are not resettable, terminating");
+ shutdown_requested = reason;
+ } else if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
shutdown_requested = reason;
} else {
reset_requested = reason;
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 0dcb9bfe13..f9584a1425 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -1029,3 +1029,8 @@ int kvm_arch_msi_data_to_gsi(uint32_t data)
{
return (data - 32) & 0xffff;
}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+ return true;
+}
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 7c2a3a123b..eefd1a11b6 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -26,6 +26,7 @@
#include "sysemu/kvm_int.h"
#include "sysemu/runstate.h"
#include "kvm_i386.h"
+#include "sev_i386.h"
#include "hyperv.h"
#include "hyperv-proto.h"
@@ -4738,3 +4739,8 @@ bool kvm_has_waitpkg(void)
{
return has_msr_umwait;
}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+ return !sev_es_enabled();
+}
diff --git a/target/mips/kvm.c b/target/mips/kvm.c
index 72637a1e02..ad612e74c1 100644
--- a/target/mips/kvm.c
+++ b/target/mips/kvm.c
@@ -1296,3 +1296,8 @@ int mips_kvm_type(MachineState *machine, const char *vm_type)
return -1;
}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+ return true;
+}
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index d85ba8ffe0..d9a4750324 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2948,3 +2948,8 @@ void kvmppc_svm_off(Error **errp)
error_setg_errno(errp, -rc, "KVM_PPC_SVM_OFF ioctl failed");
}
}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+ return true;
+}
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index f2f75d2a57..f68210373f 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -2543,3 +2543,8 @@ void kvm_s390_stop_interrupt(S390CPU *cpu)
kvm_s390_vcpu_interrupt(cpu, &irq);
}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+ return true;
+}
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest
@ 2020-09-25 19:03 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Peter Maydell, Aleksandar Rikalo, Brijesh Singh, Eduardo Habkost,
Michael S. Tsirkin, Connor Kuehl, Marcelo Tosatti,
David Hildenbrand, Dr. David Alan Gilbert, Paolo Bonzini,
David Gibson, Jiri Slaby, Aurelien Jarno, Richard Henderson
From: Tom Lendacky <thomas.lendacky@amd.com>
An SEV-ES guest does not allow register state to be altered once it has
been measured. When an SEV-ES guest issues a reboot command, Qemu will
reset the vCPU state and resume the guest. This will cause failures under
SEV-ES. Prevent that from occuring by introducing an arch-specific
callback that returns a boolean indicating whether vCPUs are resettable.
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: David Hildenbrand <david@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
accel/kvm/kvm-all.c | 5 +++++
include/sysemu/cpus.h | 2 ++
include/sysemu/hw_accel.h | 5 +++++
include/sysemu/kvm.h | 10 ++++++++++
softmmu/cpus.c | 5 +++++
softmmu/vl.c | 5 ++++-
target/arm/kvm.c | 5 +++++
target/i386/kvm.c | 6 ++++++
target/mips/kvm.c | 5 +++++
target/ppc/kvm.c | 5 +++++
target/s390x/kvm.c | 5 +++++
11 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 08b66642dd..a161fff813 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2388,6 +2388,11 @@ void kvm_flush_coalesced_mmio_buffer(void)
s->coalesced_flush_in_progress = false;
}
+bool kvm_cpu_check_are_resettable(void)
+{
+ return kvm_arch_cpu_check_are_resettable();
+}
+
static void do_kvm_cpu_synchronize_state(CPUState *cpu, run_on_cpu_data arg)
{
if (!cpu->vcpu_dirty) {
diff --git a/include/sysemu/cpus.h b/include/sysemu/cpus.h
index 3c1da6a018..d3e6cdf126 100644
--- a/include/sysemu/cpus.h
+++ b/include/sysemu/cpus.h
@@ -24,6 +24,8 @@ void dump_drift_info(void);
void qemu_cpu_kick_self(void);
void qemu_timer_notify_cb(void *opaque, QEMUClockType type);
+bool cpus_are_resettable(void);
+
void cpu_synchronize_all_states(void);
void cpu_synchronize_all_post_reset(void);
void cpu_synchronize_all_post_init(void);
diff --git a/include/sysemu/hw_accel.h b/include/sysemu/hw_accel.h
index e128f8b06b..6d387226d4 100644
--- a/include/sysemu/hw_accel.h
+++ b/include/sysemu/hw_accel.h
@@ -17,6 +17,11 @@
#include "sysemu/hvf.h"
#include "sysemu/whpx.h"
+static inline bool cpu_check_are_resettable(void)
+{
+ return kvm_enabled() ? kvm_cpu_check_are_resettable() : true;
+}
+
static inline void cpu_synchronize_state(CPUState *cpu)
{
if (kvm_enabled()) {
diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
index b7ff481d61..51a12c83ed 100644
--- a/include/sysemu/kvm.h
+++ b/include/sysemu/kvm.h
@@ -581,4 +581,14 @@ int kvm_get_max_memslots(void);
/* Notify resamplefd for EOI of specific interrupts. */
void kvm_resample_fd_notify(int gsi);
+/**
+ * kvm_cpu_check_are_resettable - return whether CPUs can be reset
+ *
+ * Returns: true: CPUs are resettable
+ * false: CPUs are not resettable
+ */
+bool kvm_cpu_check_are_resettable(void);
+
+bool kvm_arch_cpu_check_are_resettable(void);
+
#endif
diff --git a/softmmu/cpus.c b/softmmu/cpus.c
index e3b98065c9..ee9c46527c 100644
--- a/softmmu/cpus.c
+++ b/softmmu/cpus.c
@@ -927,6 +927,11 @@ void hw_error(const char *fmt, ...)
abort();
}
+bool cpus_are_resettable(void)
+{
+ return cpu_check_are_resettable();
+}
+
void cpu_synchronize_all_states(void)
{
CPUState *cpu;
diff --git a/softmmu/vl.c b/softmmu/vl.c
index f7b103467c..1f54c6b416 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -1475,7 +1475,10 @@ void qemu_system_guest_crashloaded(GuestPanicInformation *info)
void qemu_system_reset_request(ShutdownCause reason)
{
- if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
+ if (!cpus_are_resettable()) {
+ error_report("cpus are not resettable, terminating");
+ shutdown_requested = reason;
+ } else if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
shutdown_requested = reason;
} else {
reset_requested = reason;
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 0dcb9bfe13..f9584a1425 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -1029,3 +1029,8 @@ int kvm_arch_msi_data_to_gsi(uint32_t data)
{
return (data - 32) & 0xffff;
}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+ return true;
+}
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 7c2a3a123b..eefd1a11b6 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -26,6 +26,7 @@
#include "sysemu/kvm_int.h"
#include "sysemu/runstate.h"
#include "kvm_i386.h"
+#include "sev_i386.h"
#include "hyperv.h"
#include "hyperv-proto.h"
@@ -4738,3 +4739,8 @@ bool kvm_has_waitpkg(void)
{
return has_msr_umwait;
}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+ return !sev_es_enabled();
+}
diff --git a/target/mips/kvm.c b/target/mips/kvm.c
index 72637a1e02..ad612e74c1 100644
--- a/target/mips/kvm.c
+++ b/target/mips/kvm.c
@@ -1296,3 +1296,8 @@ int mips_kvm_type(MachineState *machine, const char *vm_type)
return -1;
}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+ return true;
+}
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index d85ba8ffe0..d9a4750324 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2948,3 +2948,8 @@ void kvmppc_svm_off(Error **errp)
error_setg_errno(errp, -rc, "KVM_PPC_SVM_OFF ioctl failed");
}
}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+ return true;
+}
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index f2f75d2a57..f68210373f 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -2543,3 +2543,8 @@ void kvm_s390_stop_interrupt(S390CPU *cpu)
kvm_s390_vcpu_interrupt(cpu, &irq);
}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+ return true;
+}
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 5/6] kvm/i386: Use a per-VM check for SMM capability
2020-09-25 19:03 ` Tom Lendacky
@ 2020-09-25 19:03 ` Tom Lendacky
-1 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Marcel Apfelbaum, Paolo Bonzini, Dr. David Alan Gilbert,
Eduardo Habkost, Richard Henderson, Connor Kuehl, Brijesh Singh,
Jiri Slaby, Marcelo Tosatti, Michael S. Tsirkin,
Sean Christopherson
From: Tom Lendacky <thomas.lendacky@amd.com>
SMM is not currently supported for an SEV-ES guest by KVM. Change the SMM
capability check from a KVM-wide check to a per-VM check in order to have
a finer-grained SMM capability check.
Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
target/i386/kvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index eefd1a11b6..917cdf8055 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -134,7 +134,7 @@ int kvm_has_pit_state2(void)
bool kvm_has_smm(void)
{
- return kvm_check_extension(kvm_state, KVM_CAP_X86_SMM);
+ return kvm_vm_check_extension(kvm_state, KVM_CAP_X86_SMM);
}
bool kvm_has_adjust_clock_stable(void)
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 5/6] kvm/i386: Use a per-VM check for SMM capability
@ 2020-09-25 19:03 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Sean Christopherson,
Paolo Bonzini, Jiri Slaby, Richard Henderson
From: Tom Lendacky <thomas.lendacky@amd.com>
SMM is not currently supported for an SEV-ES guest by KVM. Change the SMM
capability check from a KVM-wide check to a per-VM check in order to have
a finer-grained SMM capability check.
Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
target/i386/kvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index eefd1a11b6..917cdf8055 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -134,7 +134,7 @@ int kvm_has_pit_state2(void)
bool kvm_has_smm(void)
{
- return kvm_check_extension(kvm_state, KVM_CAP_X86_SMM);
+ return kvm_vm_check_extension(kvm_state, KVM_CAP_X86_SMM);
}
bool kvm_has_adjust_clock_stable(void)
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 6/6] sev/i386: Enable an SEV-ES guest based on SEV policy
2020-09-25 19:03 ` Tom Lendacky
@ 2020-09-25 19:03 ` Tom Lendacky
-1 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Marcel Apfelbaum, Paolo Bonzini, Dr. David Alan Gilbert,
Eduardo Habkost, Richard Henderson, Connor Kuehl, Brijesh Singh,
Jiri Slaby, Marcelo Tosatti, Michael S. Tsirkin
From: Tom Lendacky <thomas.lendacky@amd.com>
Update the sev_es_enabled() function return value to be based on the SEV
policy that has been specified. SEV-ES is enabled if SEV is enabled and
the SEV-ES policy bit is set in the policy object.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
target/i386/sev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 9c081173db..d3342f5cb2 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -377,7 +377,7 @@ sev_enabled(void)
bool
sev_es_enabled(void)
{
- return false;
+ return sev_enabled() && (sev_guest->policy & SEV_POLICY_ES);
}
uint64_t
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v4 6/6] sev/i386: Enable an SEV-ES guest based on SEV policy
@ 2020-09-25 19:03 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:03 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Paolo Bonzini,
Jiri Slaby, Richard Henderson
From: Tom Lendacky <thomas.lendacky@amd.com>
Update the sev_es_enabled() function return value to be based on the SEV
policy that has been specified. SEV-ES is enabled if SEV is enabled and
the SEV-ES policy bit is set in the policy object.
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
target/i386/sev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 9c081173db..d3342f5cb2 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -377,7 +377,7 @@ sev_enabled(void)
bool
sev_es_enabled(void)
{
- return false;
+ return sev_enabled() && (sev_guest->policy & SEV_POLICY_ES);
}
uint64_t
--
2.28.0
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
2020-09-25 19:03 ` Tom Lendacky
@ 2020-09-25 19:08 ` Tom Lendacky
-1 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:08 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Marcel Apfelbaum, Paolo Bonzini, Dr. David Alan Gilbert,
Eduardo Habkost, Richard Henderson, Connor Kuehl, Brijesh Singh,
Jiri Slaby, Marcelo Tosatti, Michael S. Tsirkin
On 9/25/20 2:03 PM, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> This patch series provides support for launching an SEV-ES guest.
>
> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
> SEV support to protect the guest register state from the hypervisor. See
> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
> section "15.35 Encrypted State (SEV-ES)" [1].
>
> 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. The notification is performed using a new exception, the VMM
> Communication exception (#VC). The information is shared through the
> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
> The GHCB format and the protocol for using it is documented in "SEV-ES
> Guest-Hypervisor Communication Block Standardization" [2].
>
> The main areas of the Qemu code that are updated to support SEV-ES are
> around the SEV guest launch process and AP booting in order to support
> booting multiple vCPUs.
>
> There are no new command line switches required. Instead, the desire for
> SEV-ES is presented using the SEV policy object. Bit 2 of the SEV policy
> object indicates that SEV-ES is required.
>
> The SEV launch process is updated in two ways. The first is that a the
> KVM_SEV_ES_INIT ioctl is used to initialize the guest instead of the
> standard KVM_SEV_INIT ioctl. The second is that before the SEV launch
> measurement is calculated, the LAUNCH_UPDATE_VMSA SEV API is invoked for
> each vCPU that Qemu has created. Once the LAUNCH_UPDATE_VMSA API has been
> invoked, no direct changes to the guest register state can be made.
>
> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
> is typically used to boot the APs. However, the hypervisor is not allowed
> to update the guest registers. For the APs, the reset vector must be known
> in advance. An OVMF method to provide a known reset vector address exists
> by providing an SEV information block, identified by UUID, near the end of
> the firmware [3]. OVMF will program the jump to the actual reset vector in
> this area of memory. Since the memory location is known in advance, an AP
> can be created with the known reset vector address as its starting CS:IP.
> The GHCB document [2] talks about how SMP booting under SEV-ES is
> performed. SEV-ES also requires the use of the in-kernel irqchip support
> in order to minimize the changes required to Qemu to support AP booting.
>
> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> [2] https://developer.amd.com/wp-content/resources/56421.pdf
> [3] 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector")
> https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847
>
> ---
>
> These patches are based on commit:
> d0ed6a69d3 ("Update version for v5.1.0 release")
>
> (I tried basing on the latest Qemu commit, but I was having build issues
> that level)
Sorry, forgot to update this part...
These patches are based on commit:
1bd5556f66 ("Merge remote-tracking branch 'remotes/kraxel/tags/audio-20200923-pull-request' into staging")
Thanks,
Tom
>
> A version of the tree can be found at:
> https://github.com/AMDESE/qemu/tree/sev-es-v12
>
> Changes since v3:
> - Use the QemuUUID structure for GUID definitions
> - Use SEV-ES policy bit definition from target/i386/sev_i386.h
> - Update SMM support to a per-VM check in order to check SMM capability
> at the VM level since SEV-ES guests don't currently support SMM
> - Make the CPU resettable check an arch-specific check
>
> Changes since v2:
> - Add in-kernel irqchip requirement for SEV-ES guests
>
> Changes since v1:
> - Fixed checkpatch.pl errors/warnings
>
> Tom Lendacky (6):
> sev/i386: Add initial support for SEV-ES
> sev/i386: Require in-kernel irqchip support for SEV-ES guests
> sev/i386: Allow AP booting under SEV-ES
> sev/i386: Don't allow a system reset under an SEV-ES guest
> kvm/i386: Use a per-VM check for SMM capability
> sev/i386: Enable an SEV-ES guest based on SEV policy
>
> accel/kvm/kvm-all.c | 69 ++++++++++++++++++++++++
> accel/stubs/kvm-stub.c | 5 ++
> hw/i386/pc_sysfw.c | 10 +++-
> include/sysemu/cpus.h | 2 +
> include/sysemu/hw_accel.h | 5 ++
> include/sysemu/kvm.h | 26 +++++++++
> include/sysemu/sev.h | 3 ++
> softmmu/cpus.c | 5 ++
> softmmu/vl.c | 5 +-
> target/arm/kvm.c | 5 ++
> target/i386/cpu.c | 1 +
> target/i386/kvm.c | 10 +++-
> target/i386/sev-stub.c | 5 ++
> target/i386/sev.c | 109 +++++++++++++++++++++++++++++++++++++-
> target/i386/sev_i386.h | 1 +
> target/mips/kvm.c | 5 ++
> target/ppc/kvm.c | 5 ++
> target/s390x/kvm.c | 5 ++
> 18 files changed, 271 insertions(+), 5 deletions(-)
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
@ 2020-09-25 19:08 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2020-09-25 19:08 UTC (permalink / raw)
To: qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Paolo Bonzini,
Jiri Slaby, Richard Henderson
On 9/25/20 2:03 PM, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> This patch series provides support for launching an SEV-ES guest.
>
> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
> SEV support to protect the guest register state from the hypervisor. See
> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
> section "15.35 Encrypted State (SEV-ES)" [1].
>
> 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. The notification is performed using a new exception, the VMM
> Communication exception (#VC). The information is shared through the
> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
> The GHCB format and the protocol for using it is documented in "SEV-ES
> Guest-Hypervisor Communication Block Standardization" [2].
>
> The main areas of the Qemu code that are updated to support SEV-ES are
> around the SEV guest launch process and AP booting in order to support
> booting multiple vCPUs.
>
> There are no new command line switches required. Instead, the desire for
> SEV-ES is presented using the SEV policy object. Bit 2 of the SEV policy
> object indicates that SEV-ES is required.
>
> The SEV launch process is updated in two ways. The first is that a the
> KVM_SEV_ES_INIT ioctl is used to initialize the guest instead of the
> standard KVM_SEV_INIT ioctl. The second is that before the SEV launch
> measurement is calculated, the LAUNCH_UPDATE_VMSA SEV API is invoked for
> each vCPU that Qemu has created. Once the LAUNCH_UPDATE_VMSA API has been
> invoked, no direct changes to the guest register state can be made.
>
> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
> is typically used to boot the APs. However, the hypervisor is not allowed
> to update the guest registers. For the APs, the reset vector must be known
> in advance. An OVMF method to provide a known reset vector address exists
> by providing an SEV information block, identified by UUID, near the end of
> the firmware [3]. OVMF will program the jump to the actual reset vector in
> this area of memory. Since the memory location is known in advance, an AP
> can be created with the known reset vector address as its starting CS:IP.
> The GHCB document [2] talks about how SMP booting under SEV-ES is
> performed. SEV-ES also requires the use of the in-kernel irqchip support
> in order to minimize the changes required to Qemu to support AP booting.
>
> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> [2] https://developer.amd.com/wp-content/resources/56421.pdf
> [3] 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector")
> https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847
>
> ---
>
> These patches are based on commit:
> d0ed6a69d3 ("Update version for v5.1.0 release")
>
> (I tried basing on the latest Qemu commit, but I was having build issues
> that level)
Sorry, forgot to update this part...
These patches are based on commit:
1bd5556f66 ("Merge remote-tracking branch 'remotes/kraxel/tags/audio-20200923-pull-request' into staging")
Thanks,
Tom
>
> A version of the tree can be found at:
> https://github.com/AMDESE/qemu/tree/sev-es-v12
>
> Changes since v3:
> - Use the QemuUUID structure for GUID definitions
> - Use SEV-ES policy bit definition from target/i386/sev_i386.h
> - Update SMM support to a per-VM check in order to check SMM capability
> at the VM level since SEV-ES guests don't currently support SMM
> - Make the CPU resettable check an arch-specific check
>
> Changes since v2:
> - Add in-kernel irqchip requirement for SEV-ES guests
>
> Changes since v1:
> - Fixed checkpatch.pl errors/warnings
>
> Tom Lendacky (6):
> sev/i386: Add initial support for SEV-ES
> sev/i386: Require in-kernel irqchip support for SEV-ES guests
> sev/i386: Allow AP booting under SEV-ES
> sev/i386: Don't allow a system reset under an SEV-ES guest
> kvm/i386: Use a per-VM check for SMM capability
> sev/i386: Enable an SEV-ES guest based on SEV policy
>
> accel/kvm/kvm-all.c | 69 ++++++++++++++++++++++++
> accel/stubs/kvm-stub.c | 5 ++
> hw/i386/pc_sysfw.c | 10 +++-
> include/sysemu/cpus.h | 2 +
> include/sysemu/hw_accel.h | 5 ++
> include/sysemu/kvm.h | 26 +++++++++
> include/sysemu/sev.h | 3 ++
> softmmu/cpus.c | 5 ++
> softmmu/vl.c | 5 +-
> target/arm/kvm.c | 5 ++
> target/i386/cpu.c | 1 +
> target/i386/kvm.c | 10 +++-
> target/i386/sev-stub.c | 5 ++
> target/i386/sev.c | 109 +++++++++++++++++++++++++++++++++++++-
> target/i386/sev_i386.h | 1 +
> target/mips/kvm.c | 5 ++
> target/ppc/kvm.c | 5 ++
> target/s390x/kvm.c | 5 ++
> 18 files changed, 271 insertions(+), 5 deletions(-)
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
2020-09-25 19:03 ` Tom Lendacky
@ 2020-09-25 22:57 ` no-reply
-1 siblings, 0 replies; 30+ messages in thread
From: no-reply @ 2020-09-25 22:57 UTC (permalink / raw)
To: thomas.lendacky
Cc: qemu-devel, kvm, brijesh.singh, ehabkost, mst, ckuehl, mtosatti,
dgilbert, pbonzini, jslaby, rth
Patchew URL: https://patchew.org/QEMU/cover.1601060620.git.thomas.lendacky@amd.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===
C linker for the host machine: cc ld.bfd 2.27-43
Host machine cpu family: x86_64
Host machine cpu: x86_64
../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or forwards compatibility and might not exist in future releases.
Program sh found: YES
Program python3 found: YES (/usr/bin/python3)
Configuring ninjatool using configuration
---
TEST iotest-qcow2: 029
socket_accept failed: Resource temporarily unavailable
**
ERROR:../src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0)
../src/tests/qtest/libqtest.c:166: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0)
ERROR qtest-x86_64: bios-tables-test - Bail out! ERROR:../src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0)
make: *** [run-test-138] Error 1
make: *** Waiting for unfinished jobs....
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--rm', '--label', 'com.qemu.instance.uuid=ac8de816386f43fbbd35e8eef7710385', '-u', '1001', '--security-opt', 'seccomp=unconfined', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-hmf8po3g/src/docker-src.2020-09-25-18.40.32.24005:/var/tmp/qemu:z,ro', 'qemu/centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=ac8de816386f43fbbd35e8eef7710385
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-hmf8po3g/src'
make: *** [docker-run-test-quick@centos7] Error 2
real 17m23.414s
user 0m21.953s
The full log is available at
http://patchew.org/logs/cover.1601060620.git.thomas.lendacky@amd.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
@ 2020-09-25 22:57 ` no-reply
0 siblings, 0 replies; 30+ messages in thread
From: no-reply @ 2020-09-25 22:57 UTC (permalink / raw)
To: thomas.lendacky
Cc: brijesh.singh, ehabkost, kvm, mst, ckuehl, mtosatti, qemu-devel,
dgilbert, pbonzini, jslaby, rth
Patchew URL: https://patchew.org/QEMU/cover.1601060620.git.thomas.lendacky@amd.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===
C linker for the host machine: cc ld.bfd 2.27-43
Host machine cpu family: x86_64
Host machine cpu: x86_64
../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or forwards compatibility and might not exist in future releases.
Program sh found: YES
Program python3 found: YES (/usr/bin/python3)
Configuring ninjatool using configuration
---
TEST iotest-qcow2: 029
socket_accept failed: Resource temporarily unavailable
**
ERROR:../src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0)
../src/tests/qtest/libqtest.c:166: kill_qemu() tried to terminate QEMU process but encountered exit status 1 (expected 0)
ERROR qtest-x86_64: bios-tables-test - Bail out! ERROR:../src/tests/qtest/libqtest.c:301:qtest_init_without_qmp_handshake: assertion failed: (s->fd >= 0 && s->qmp_fd >= 0)
make: *** [run-test-138] Error 1
make: *** Waiting for unfinished jobs....
Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: -accel kvm: failed to initialize kvm: No such file or directory
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', '--rm', '--label', 'com.qemu.instance.uuid=ac8de816386f43fbbd35e8eef7710385', '-u', '1001', '--security-opt', 'seccomp=unconfined', '-e', 'TARGET_LIST=', '-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', '/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', '/var/tmp/patchew-tester-tmp-hmf8po3g/src/docker-src.2020-09-25-18.40.32.24005:/var/tmp/qemu:z,ro', 'qemu/centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit status 2.
filter=--filter=label=com.qemu.instance.uuid=ac8de816386f43fbbd35e8eef7710385
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-hmf8po3g/src'
make: *** [docker-run-test-quick@centos7] Error 2
real 17m23.414s
user 0m21.953s
The full log is available at
http://patchew.org/logs/cover.1601060620.git.thomas.lendacky@amd.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest
2020-09-25 19:03 ` Tom Lendacky
@ 2021-01-26 16:16 ` Paolo Bonzini
-1 siblings, 0 replies; 30+ messages in thread
From: Paolo Bonzini @ 2021-01-26 16:16 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel, kvm
Cc: Marcel Apfelbaum, Dr. David Alan Gilbert, Eduardo Habkost,
Richard Henderson, Connor Kuehl, Brijesh Singh, Jiri Slaby,
Marcelo Tosatti, Michael S. Tsirkin, Peter Maydell,
Aurelien Jarno, Jiaxun Yang, Aleksandar Rikalo, David Gibson,
David Hildenbrand
On 25/09/20 21:03, Tom Lendacky wrote:
>
> {
> - if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
> + if (!cpus_are_resettable()) {
> + error_report("cpus are not resettable, terminating");
> + shutdown_requested = reason;
> + } else if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
The error should not be emitted if "no_reboot && reason !=
SHUTDOWN_CAUSE_SUBSYSTEM_RESET" (the condition has changed a bit in
latest QEMU but the idea is the same).
This is because whoever invoked QEMU could already know about this
SEV-ES limitation, and use -no-reboot (aka -action reset=shutdown in
6.0) in order to change the forbidden warm reset into a shutdown+restart
cold reset.
Paolo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest
@ 2021-01-26 16:16 ` Paolo Bonzini
0 siblings, 0 replies; 30+ messages in thread
From: Paolo Bonzini @ 2021-01-26 16:16 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel, kvm
Cc: Peter Maydell, Aleksandar Rikalo, Brijesh Singh, Eduardo Habkost,
Michael S. Tsirkin, Connor Kuehl, Marcelo Tosatti,
David Hildenbrand, Dr. David Alan Gilbert, David Gibson,
Jiri Slaby, Aurelien Jarno, Richard Henderson
On 25/09/20 21:03, Tom Lendacky wrote:
>
> {
> - if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
> + if (!cpus_are_resettable()) {
> + error_report("cpus are not resettable, terminating");
> + shutdown_requested = reason;
> + } else if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
The error should not be emitted if "no_reboot && reason !=
SHUTDOWN_CAUSE_SUBSYSTEM_RESET" (the condition has changed a bit in
latest QEMU but the idea is the same).
This is because whoever invoked QEMU could already know about this
SEV-ES limitation, and use -no-reboot (aka -action reset=shutdown in
6.0) in order to change the forbidden warm reset into a shutdown+restart
cold reset.
Paolo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
2020-09-25 19:03 ` Tom Lendacky
@ 2021-01-26 16:21 ` Paolo Bonzini
-1 siblings, 0 replies; 30+ messages in thread
From: Paolo Bonzini @ 2021-01-26 16:21 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel, kvm
Cc: Marcel Apfelbaum, Dr. David Alan Gilbert, Eduardo Habkost,
Richard Henderson, Connor Kuehl, Brijesh Singh, Jiri Slaby,
Marcelo Tosatti, Michael S. Tsirkin
On 25/09/20 21:03, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> This patch series provides support for launching an SEV-ES guest.
>
> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
> SEV support to protect the guest register state from the hypervisor. See
> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
> section "15.35 Encrypted State (SEV-ES)" [1].
>
> 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. The notification is performed using a new exception, the VMM
> Communication exception (#VC). The information is shared through the
> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
> The GHCB format and the protocol for using it is documented in "SEV-ES
> Guest-Hypervisor Communication Block Standardization" [2].
>
> The main areas of the Qemu code that are updated to support SEV-ES are
> around the SEV guest launch process and AP booting in order to support
> booting multiple vCPUs.
>
> There are no new command line switches required. Instead, the desire for
> SEV-ES is presented using the SEV policy object. Bit 2 of the SEV policy
> object indicates that SEV-ES is required.
>
> The SEV launch process is updated in two ways. The first is that a the
> KVM_SEV_ES_INIT ioctl is used to initialize the guest instead of the
> standard KVM_SEV_INIT ioctl. The second is that before the SEV launch
> measurement is calculated, the LAUNCH_UPDATE_VMSA SEV API is invoked for
> each vCPU that Qemu has created. Once the LAUNCH_UPDATE_VMSA API has been
> invoked, no direct changes to the guest register state can be made.
>
> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
> is typically used to boot the APs. However, the hypervisor is not allowed
> to update the guest registers. For the APs, the reset vector must be known
> in advance. An OVMF method to provide a known reset vector address exists
> by providing an SEV information block, identified by UUID, near the end of
> the firmware [3]. OVMF will program the jump to the actual reset vector in
> this area of memory. Since the memory location is known in advance, an AP
> can be created with the known reset vector address as its starting CS:IP.
> The GHCB document [2] talks about how SMP booting under SEV-ES is
> performed. SEV-ES also requires the use of the in-kernel irqchip support
> in order to minimize the changes required to Qemu to support AP booting.
>
> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> [2] https://developer.amd.com/wp-content/resources/56421.pdf
> [3] 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector")
> https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847
>
> ---
>
> These patches are based on commit:
> d0ed6a69d3 ("Update version for v5.1.0 release")
>
> (I tried basing on the latest Qemu commit, but I was having build issues
> that level)
>
> A version of the tree can be found at:
> https://github.com/AMDESE/qemu/tree/sev-es-v12
>
> Changes since v3:
> - Use the QemuUUID structure for GUID definitions
> - Use SEV-ES policy bit definition from target/i386/sev_i386.h
> - Update SMM support to a per-VM check in order to check SMM capability
> at the VM level since SEV-ES guests don't currently support SMM
> - Make the CPU resettable check an arch-specific check
>
> Changes since v2:
> - Add in-kernel irqchip requirement for SEV-ES guests
>
> Changes since v1:
> - Fixed checkpatch.pl errors/warnings
>
> Tom Lendacky (6):
> sev/i386: Add initial support for SEV-ES
> sev/i386: Require in-kernel irqchip support for SEV-ES guests
> sev/i386: Allow AP booting under SEV-ES
> sev/i386: Don't allow a system reset under an SEV-ES guest
> kvm/i386: Use a per-VM check for SMM capability
> sev/i386: Enable an SEV-ES guest based on SEV policy
>
> accel/kvm/kvm-all.c | 69 ++++++++++++++++++++++++
> accel/stubs/kvm-stub.c | 5 ++
> hw/i386/pc_sysfw.c | 10 +++-
> include/sysemu/cpus.h | 2 +
> include/sysemu/hw_accel.h | 5 ++
> include/sysemu/kvm.h | 26 +++++++++
> include/sysemu/sev.h | 3 ++
> softmmu/cpus.c | 5 ++
> softmmu/vl.c | 5 +-
> target/arm/kvm.c | 5 ++
> target/i386/cpu.c | 1 +
> target/i386/kvm.c | 10 +++-
> target/i386/sev-stub.c | 5 ++
> target/i386/sev.c | 109 +++++++++++++++++++++++++++++++++++++-
> target/i386/sev_i386.h | 1 +
> target/mips/kvm.c | 5 ++
> target/ppc/kvm.c | 5 ++
> target/s390x/kvm.c | 5 ++
> 18 files changed, 271 insertions(+), 5 deletions(-)
>
Looks good! Please fix the nit in patch 4 and rebase, I'll then apply it.
Thanks,
Paolo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
@ 2021-01-26 16:21 ` Paolo Bonzini
0 siblings, 0 replies; 30+ messages in thread
From: Paolo Bonzini @ 2021-01-26 16:21 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Jiri Slaby,
Richard Henderson
On 25/09/20 21:03, Tom Lendacky wrote:
> From: Tom Lendacky <thomas.lendacky@amd.com>
>
> This patch series provides support for launching an SEV-ES guest.
>
> Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
> SEV support to protect the guest register state from the hypervisor. See
> "AMD64 Architecture Programmer's Manual Volume 2: System Programming",
> section "15.35 Encrypted State (SEV-ES)" [1].
>
> 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. The notification is performed using a new exception, the VMM
> Communication exception (#VC). The information is shared through the
> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
> The GHCB format and the protocol for using it is documented in "SEV-ES
> Guest-Hypervisor Communication Block Standardization" [2].
>
> The main areas of the Qemu code that are updated to support SEV-ES are
> around the SEV guest launch process and AP booting in order to support
> booting multiple vCPUs.
>
> There are no new command line switches required. Instead, the desire for
> SEV-ES is presented using the SEV policy object. Bit 2 of the SEV policy
> object indicates that SEV-ES is required.
>
> The SEV launch process is updated in two ways. The first is that a the
> KVM_SEV_ES_INIT ioctl is used to initialize the guest instead of the
> standard KVM_SEV_INIT ioctl. The second is that before the SEV launch
> measurement is calculated, the LAUNCH_UPDATE_VMSA SEV API is invoked for
> each vCPU that Qemu has created. Once the LAUNCH_UPDATE_VMSA API has been
> invoked, no direct changes to the guest register state can be made.
>
> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
> is typically used to boot the APs. However, the hypervisor is not allowed
> to update the guest registers. For the APs, the reset vector must be known
> in advance. An OVMF method to provide a known reset vector address exists
> by providing an SEV information block, identified by UUID, near the end of
> the firmware [3]. OVMF will program the jump to the actual reset vector in
> this area of memory. Since the memory location is known in advance, an AP
> can be created with the known reset vector address as its starting CS:IP.
> The GHCB document [2] talks about how SMP booting under SEV-ES is
> performed. SEV-ES also requires the use of the in-kernel irqchip support
> in order to minimize the changes required to Qemu to support AP booting.
>
> [1] https://www.amd.com/system/files/TechDocs/24593.pdf
> [2] https://developer.amd.com/wp-content/resources/56421.pdf
> [3] 30937f2f98c4 ("OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector")
> https://github.com/tianocore/edk2/commit/30937f2f98c42496f2f143fe8374ae7f7e684847
>
> ---
>
> These patches are based on commit:
> d0ed6a69d3 ("Update version for v5.1.0 release")
>
> (I tried basing on the latest Qemu commit, but I was having build issues
> that level)
>
> A version of the tree can be found at:
> https://github.com/AMDESE/qemu/tree/sev-es-v12
>
> Changes since v3:
> - Use the QemuUUID structure for GUID definitions
> - Use SEV-ES policy bit definition from target/i386/sev_i386.h
> - Update SMM support to a per-VM check in order to check SMM capability
> at the VM level since SEV-ES guests don't currently support SMM
> - Make the CPU resettable check an arch-specific check
>
> Changes since v2:
> - Add in-kernel irqchip requirement for SEV-ES guests
>
> Changes since v1:
> - Fixed checkpatch.pl errors/warnings
>
> Tom Lendacky (6):
> sev/i386: Add initial support for SEV-ES
> sev/i386: Require in-kernel irqchip support for SEV-ES guests
> sev/i386: Allow AP booting under SEV-ES
> sev/i386: Don't allow a system reset under an SEV-ES guest
> kvm/i386: Use a per-VM check for SMM capability
> sev/i386: Enable an SEV-ES guest based on SEV policy
>
> accel/kvm/kvm-all.c | 69 ++++++++++++++++++++++++
> accel/stubs/kvm-stub.c | 5 ++
> hw/i386/pc_sysfw.c | 10 +++-
> include/sysemu/cpus.h | 2 +
> include/sysemu/hw_accel.h | 5 ++
> include/sysemu/kvm.h | 26 +++++++++
> include/sysemu/sev.h | 3 ++
> softmmu/cpus.c | 5 ++
> softmmu/vl.c | 5 +-
> target/arm/kvm.c | 5 ++
> target/i386/cpu.c | 1 +
> target/i386/kvm.c | 10 +++-
> target/i386/sev-stub.c | 5 ++
> target/i386/sev.c | 109 +++++++++++++++++++++++++++++++++++++-
> target/i386/sev_i386.h | 1 +
> target/mips/kvm.c | 5 ++
> target/ppc/kvm.c | 5 ++
> target/s390x/kvm.c | 5 ++
> 18 files changed, 271 insertions(+), 5 deletions(-)
>
Looks good! Please fix the nit in patch 4 and rebase, I'll then apply it.
Thanks,
Paolo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest
2021-01-26 16:16 ` Paolo Bonzini
@ 2021-01-26 16:24 ` Tom Lendacky
-1 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2021-01-26 16:24 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel, kvm
Cc: Marcel Apfelbaum, Dr. David Alan Gilbert, Eduardo Habkost,
Richard Henderson, Connor Kuehl, Brijesh Singh, Jiri Slaby,
Marcelo Tosatti, Michael S. Tsirkin, Peter Maydell,
Aurelien Jarno, Jiaxun Yang, Aleksandar Rikalo, David Gibson,
David Hildenbrand
On 1/26/21 10:16 AM, Paolo Bonzini wrote:
> On 25/09/20 21:03, Tom Lendacky wrote:
>>
>> {
>> - if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
>> + if (!cpus_are_resettable()) {
>> + error_report("cpus are not resettable, terminating");
>> + shutdown_requested = reason;
>> + } else if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
>
> The error should not be emitted if "no_reboot && reason !=
> SHUTDOWN_CAUSE_SUBSYSTEM_RESET" (the condition has changed a bit in latest
> QEMU but the idea is the same).
>
> This is because whoever invoked QEMU could already know about this SEV-ES
> limitation, and use -no-reboot (aka -action reset=shutdown in 6.0) in
> order to change the forbidden warm reset into a shutdown+restart cold reset.
Ah, right. Let me re-work this to not emit the message when it is not
warranted.
Thanks,
Tom
>
> Paolo
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest
@ 2021-01-26 16:24 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2021-01-26 16:24 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel, kvm
Cc: Peter Maydell, Aleksandar Rikalo, Brijesh Singh, Eduardo Habkost,
Michael S. Tsirkin, Connor Kuehl, Marcelo Tosatti,
David Hildenbrand, Dr. David Alan Gilbert, David Gibson,
Jiri Slaby, Aurelien Jarno, Richard Henderson
On 1/26/21 10:16 AM, Paolo Bonzini wrote:
> On 25/09/20 21:03, Tom Lendacky wrote:
>>
>> {
>> - if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
>> + if (!cpus_are_resettable()) {
>> + error_report("cpus are not resettable, terminating");
>> + shutdown_requested = reason;
>> + } else if (no_reboot && reason != SHUTDOWN_CAUSE_SUBSYSTEM_RESET) {
>
> The error should not be emitted if "no_reboot && reason !=
> SHUTDOWN_CAUSE_SUBSYSTEM_RESET" (the condition has changed a bit in latest
> QEMU but the idea is the same).
>
> This is because whoever invoked QEMU could already know about this SEV-ES
> limitation, and use -no-reboot (aka -action reset=shutdown in 6.0) in
> order to change the forbidden warm reset into a shutdown+restart cold reset.
Ah, right. Let me re-work this to not emit the message when it is not
warranted.
Thanks,
Tom
>
> Paolo
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
2021-01-26 16:21 ` Paolo Bonzini
@ 2021-01-26 16:49 ` Tom Lendacky
-1 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2021-01-26 16:49 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel, kvm
Cc: Marcel Apfelbaum, Dr. David Alan Gilbert, Eduardo Habkost,
Richard Henderson, Connor Kuehl, Brijesh Singh, Jiri Slaby,
Marcelo Tosatti, Michael S. Tsirkin
On 1/26/21 10:21 AM, Paolo Bonzini wrote:
> On 25/09/20 21:03, Tom Lendacky wrote:
>> From: Tom Lendacky <thomas.lendacky@amd.com>
>>
>> This patch series provides support for launching an SEV-ES guest.
>>
...
>>
>
> Looks good! Please fix the nit in patch 4 and rebase, I'll then apply it.
There's a v5 on the list that was rebased on the latest tree, but still
has the patch 4 issue. I'm updating that now, so look for the v6 version
for merging.
Thanks,
Tom
>
> Thanks,
>
> Paolo
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
@ 2021-01-26 16:49 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2021-01-26 16:49 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Jiri Slaby,
Richard Henderson
On 1/26/21 10:21 AM, Paolo Bonzini wrote:
> On 25/09/20 21:03, Tom Lendacky wrote:
>> From: Tom Lendacky <thomas.lendacky@amd.com>
>>
>> This patch series provides support for launching an SEV-ES guest.
>>
...
>>
>
> Looks good! Please fix the nit in patch 4 and rebase, I'll then apply it.
There's a v5 on the list that was rebased on the latest tree, but still
has the patch 4 issue. I'm updating that now, so look for the v6 version
for merging.
Thanks,
Tom
>
> Thanks,
>
> Paolo
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
2021-01-26 16:49 ` Tom Lendacky
@ 2021-01-26 17:13 ` Tom Lendacky
-1 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2021-01-26 17:13 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel, kvm
Cc: Marcel Apfelbaum, Dr. David Alan Gilbert, Eduardo Habkost,
Richard Henderson, Connor Kuehl, Brijesh Singh, Jiri Slaby,
Marcelo Tosatti, Michael S. Tsirkin
On 1/26/21 10:49 AM, Tom Lendacky wrote:
> On 1/26/21 10:21 AM, Paolo Bonzini wrote:
>> On 25/09/20 21:03, Tom Lendacky wrote:
>>> From: Tom Lendacky <thomas.lendacky@amd.com>
>>>
>>> This patch series provides support for launching an SEV-ES guest.
>>>
>
> ...
>
>>>
>>
>> Looks good! Please fix the nit in patch 4 and rebase, I'll then apply it.
>
> There's a v5 on the list that was rebased on the latest tree, but still
> has the patch 4 issue. I'm updating that now, so look for the v6 version
> for merging.
Also, the new version will have a prereq against another patch series that
has not been accepted yet:
[PATCH v2 0/2] sev: enable secret injection to a self described area in OVMF
https://lore.kernel.org/qemu-devel/20201214154429.11023-1-jejb@linux.ibm.com/
Thanks,
Tom
>
> Thanks,
> Tom
>
>>
>> Thanks,
>>
>> Paolo
>>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
@ 2021-01-26 17:13 ` Tom Lendacky
0 siblings, 0 replies; 30+ messages in thread
From: Tom Lendacky @ 2021-01-26 17:13 UTC (permalink / raw)
To: Paolo Bonzini, qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Jiri Slaby,
Richard Henderson
On 1/26/21 10:49 AM, Tom Lendacky wrote:
> On 1/26/21 10:21 AM, Paolo Bonzini wrote:
>> On 25/09/20 21:03, Tom Lendacky wrote:
>>> From: Tom Lendacky <thomas.lendacky@amd.com>
>>>
>>> This patch series provides support for launching an SEV-ES guest.
>>>
>
> ...
>
>>>
>>
>> Looks good! Please fix the nit in patch 4 and rebase, I'll then apply it.
>
> There's a v5 on the list that was rebased on the latest tree, but still
> has the patch 4 issue. I'm updating that now, so look for the v6 version
> for merging.
Also, the new version will have a prereq against another patch series that
has not been accepted yet:
[PATCH v2 0/2] sev: enable secret injection to a self described area in OVMF
https://lore.kernel.org/qemu-devel/20201214154429.11023-1-jejb@linux.ibm.com/
Thanks,
Tom
>
> Thanks,
> Tom
>
>>
>> Thanks,
>>
>> Paolo
>>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
2021-01-26 17:13 ` Tom Lendacky
@ 2021-01-26 17:18 ` Paolo Bonzini
-1 siblings, 0 replies; 30+ messages in thread
From: Paolo Bonzini @ 2021-01-26 17:18 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel, kvm
Cc: Marcel Apfelbaum, Dr. David Alan Gilbert, Eduardo Habkost,
Richard Henderson, Connor Kuehl, Brijesh Singh, Jiri Slaby,
Marcelo Tosatti, Michael S. Tsirkin
On 26/01/21 18:13, Tom Lendacky wrote:
> Also, the new version will have a prereq against another patch series that
> has not been accepted yet:
>
> [PATCH v2 0/2] sev: enable secret injection to a self described area in OVMF
>
> https://lore.kernel.org/qemu-devel/20201214154429.11023-1-jejb@linux.ibm.com/
David reviewed it today, so even if a v3 will be needed that shouldn't
be a problem for SEV-ES itself.
Paolo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v4 0/6] Qemu SEV-ES guest support
@ 2021-01-26 17:18 ` Paolo Bonzini
0 siblings, 0 replies; 30+ messages in thread
From: Paolo Bonzini @ 2021-01-26 17:18 UTC (permalink / raw)
To: Tom Lendacky, qemu-devel, kvm
Cc: Brijesh Singh, Eduardo Habkost, Michael S. Tsirkin, Connor Kuehl,
Marcelo Tosatti, Dr. David Alan Gilbert, Jiri Slaby,
Richard Henderson
On 26/01/21 18:13, Tom Lendacky wrote:
> Also, the new version will have a prereq against another patch series that
> has not been accepted yet:
>
> [PATCH v2 0/2] sev: enable secret injection to a self described area in OVMF
>
> https://lore.kernel.org/qemu-devel/20201214154429.11023-1-jejb@linux.ibm.com/
David reviewed it today, so even if a v3 will be needed that shouldn't
be a problem for SEV-ES itself.
Paolo
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2021-01-27 13:31 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-25 19:03 [PATCH v4 0/6] Qemu SEV-ES guest support Tom Lendacky
2020-09-25 19:03 ` Tom Lendacky
2020-09-25 19:03 ` [PATCH v4 1/6] sev/i386: Add initial support for SEV-ES Tom Lendacky
2020-09-25 19:03 ` Tom Lendacky
2020-09-25 19:03 ` [PATCH v4 2/6] sev/i386: Require in-kernel irqchip support for SEV-ES guests Tom Lendacky
2020-09-25 19:03 ` Tom Lendacky
2020-09-25 19:03 ` [PATCH v4 3/6] sev/i386: Allow AP booting under SEV-ES Tom Lendacky
2020-09-25 19:03 ` Tom Lendacky
2020-09-25 19:03 ` [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest Tom Lendacky
2020-09-25 19:03 ` Tom Lendacky
2021-01-26 16:16 ` Paolo Bonzini
2021-01-26 16:16 ` Paolo Bonzini
2021-01-26 16:24 ` Tom Lendacky
2021-01-26 16:24 ` Tom Lendacky
2020-09-25 19:03 ` [PATCH v4 5/6] kvm/i386: Use a per-VM check for SMM capability Tom Lendacky
2020-09-25 19:03 ` Tom Lendacky
2020-09-25 19:03 ` [PATCH v4 6/6] sev/i386: Enable an SEV-ES guest based on SEV policy Tom Lendacky
2020-09-25 19:03 ` Tom Lendacky
2020-09-25 19:08 ` [PATCH v4 0/6] Qemu SEV-ES guest support Tom Lendacky
2020-09-25 19:08 ` Tom Lendacky
2020-09-25 22:57 ` no-reply
2020-09-25 22:57 ` no-reply
2021-01-26 16:21 ` Paolo Bonzini
2021-01-26 16:21 ` Paolo Bonzini
2021-01-26 16:49 ` Tom Lendacky
2021-01-26 16:49 ` Tom Lendacky
2021-01-26 17:13 ` Tom Lendacky
2021-01-26 17:13 ` Tom Lendacky
2021-01-26 17:18 ` Paolo Bonzini
2021-01-26 17:18 ` Paolo Bonzini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.