Skip to contentSkip to conversation

Qemu SEV-ES guest support

PATCH Superseded Tom Lendacky 3 participants 15 messages Sep 25, 2020 – Jan 26, 2021 KVM

v4 of 6 Superseded Latest is v6 →

lore
Share & tools
lore
#0 lore raw

v4 cover Qemu SEV-ES guest support

From: Tom Lendacky <[email protected]>

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(-)
Signature · 1 line
2.28.0
#1 lore raw

PATCH v4 1/6 sev/i386: Add initial support for SEV-ES

From: Tom Lendacky <[email protected]>

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.

---
 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(-)
target/i386/cpu.c +1 -0
index 3ffd877dd5..ca0e17ed07 100644
@@ -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;
target/i386/sev-stub.c +5 -0
index 88e3f39a1e..040ac90563 100644
@@ -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;
+}
target/i386/sev.c +42 -2

75 lines not on this page · raw message

target/i386/sev_i386.h +1 -0
index 4db6960f60..4f9a5e9b21 100644
@@ -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);
Signature · 1 line
2.28.0
#3 lore raw

PATCH v4 3/6 sev/i386: Allow AP booting under SEV-ES

In reply to Tom Lendacky

From: Tom Lendacky <[email protected]>

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.

---
 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(-)
accel/kvm/kvm-all.c +64 -0
index ad8b315b35..08b66642dd 100644
@@ -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);
accel/stubs/kvm-stub.c +5 -0
index 82f118d2df..3aece9b513 100644
@@ -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)
 {
hw/i386/pc_sysfw.c +9 -1
index b6c0822fe3..321ff94261 100644
@@ -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");
include/sysemu/kvm.h +16 -0
index 5bbea53883..b7ff481d61 100644
@@ -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"
include/sysemu/sev.h +3 -0
index 98c1ec8d38..5198e5a621 100644
@@ -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
target/i386/kvm.c +2 -0
index 9efb07e7c8..7c2a3a123b 100644
@@ -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)
target/i386/sev.c +59 -0

77 lines not on this page · raw message

Signature · 1 line
2.28.0
#7 lore raw

PATCH v4 5/6 kvm/i386: Use a per-VM check for SMM capability

In reply to Tom Lendacky

From: Tom Lendacky <[email protected]>

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.

---
 target/i386/kvm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
target/i386/kvm.c +1 -1
index eefd1a11b6..917cdf8055 100644
@@ -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)
Signature · 1 line
2.28.0
#4 lore raw

PATCH v4 4/6 sev/i386: Don't allow a system reset under an SEV-ES guest

In reply to Tom Lendacky

From: Tom Lendacky <[email protected]>

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 <[email protected]>
Cc Aurelien Jarno <[email protected]>
Cc Jiaxun Yang <[email protected]>
Cc Aleksandar Rikalo <[email protected]>
Cc David Gibson <[email protected]>
Cc David Hildenbrand <[email protected]>
---
 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(-)
accel/kvm/kvm-all.c +5 -0
index 08b66642dd..a161fff813 100644
@@ -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) {
include/sysemu/cpus.h +2 -0
index 3c1da6a018..d3e6cdf126 100644
@@ -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);
include/sysemu/hw_accel.h +5 -0
index e128f8b06b..6d387226d4 100644
@@ -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()) {
include/sysemu/kvm.h +10 -0
index b7ff481d61..51a12c83ed 100644
@@ -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
softmmu/cpus.c +5 -0
index e3b98065c9..ee9c46527c 100644
@@ -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;
softmmu/vl.c +4 -1
index f7b103467c..1f54c6b416 100644
@@ -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;
target/arm/kvm.c +5 -0
index 0dcb9bfe13..f9584a1425 100644
@@ -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;
+}
target/i386/kvm.c +6 -0
index 7c2a3a123b..eefd1a11b6 100644
@@ -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();
+}
target/mips/kvm.c +5 -0
index 72637a1e02..ad612e74c1 100644
@@ -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;
+}
target/ppc/kvm.c +5 -0
index d85ba8ffe0..d9a4750324 100644
@@ -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;
+}
target/s390x/kvm.c +5 -0
index f2f75d2a57..f68210373f 100644
@@ -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;
+}
Signature · 1 line
2.28.0
#2 lore raw

PATCH v4 2/6 sev/i386: Require in-kernel irqchip support for SEV-ES guests

In reply to Tom Lendacky

From: Tom Lendacky <[email protected]>

In prep for AP booting, require the use of in-kernel irqchip support. This lessens the Qemu support burden required to boot APs.

---
 target/i386/sev.c | 6 ++++++
 1 file changed, 6 insertions(+)
target/i386/sev.c +6 -0
index af6b88691f..0d4bd3cd75 100644
@@ -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",
Signature · 1 line
2.28.0
#8 lore raw

PATCH v4 6/6 sev/i386: Enable an SEV-ES guest based on SEV policy

In reply to Tom Lendacky

From: Tom Lendacky <[email protected]>

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.

---
 target/i386/sev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
target/i386/sev.c +1 -1
index 9c081173db..d3342f5cb2 100644
@@ -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
Signature · 1 line
2.28.0
#9 lore raw
In reply to Tom Lendacky
Quoted 51 lines · Tom Lendacky

From: Tom Lendacky <[email protected]>

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
Quoted 7 lines

---

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

Quoted 45 lines

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(-)
#10 lore raw
In reply to Tom Lendacky
Patchew URL: https://patchew.org/QEMU/[email protected]/

Patchew URL: https://patchew.org/QEMU/[email protected]/

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/[email protected]/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to [email protected]

maintainer
#5 lore raw

Re: [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest

In reply to Tom Lendacky

softmmu/vl.c void qemu_system_guest_crashloaded(GuestPanicInformation *info) · line 1481

Quoted 7 lines · Tom Lendacky

{

softmmu/vl.c +4 -1
-    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

maintainer
#11 lore raw
In reply to Tom Lendacky
Quoted 94 lines · Tom Lendacky

From: Tom Lendacky <[email protected]>

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 +
Quoted 9 lines
  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

#6 lore raw

Re: [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest

In reply to Paolo Bonzini
Quoted 9 lines · Paolo Bonzini
Quoted 7 lines · Tom Lendacky

 {
-    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) {

Quoted 7 lines

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

Quoted 3 lines

Paolo

#12 lore raw
In reply to Paolo Bonzini
Quoted 5 lines · Paolo Bonzini
Quoted 4 lines · Tom Lendacky

From: Tom Lendacky <[email protected]>

This patch series provides support for launching an SEV-ES guest.

...

Quoted 3 lines
Quoted 1 line

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

Quoted 5 lines

Thanks,

Paolo

#13 lore raw
Quoted 11 lines · Tom Lendacky
Quoted 5 lines · Paolo Bonzini
Quoted 4 lines · Tom Lendacky

From: Tom Lendacky <[email protected]>

This patch series provides support for launching an SEV-ES guest.

...

Quoted 2 lines
Quoted 1 line
Quoted 5 lines
Quoted 1 line

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/[email protected]/

Thanks,
Tom

Quoted 9 lines

Thanks,
Tom

Quoted 5 lines

Thanks,

Paolo

maintainer
#14 lore raw
Quoted 6 lines · Tom Lendacky

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/[email protected]/

David reviewed it today, so even if a v3 will be needed that shouldn't be a problem for SEV-ES itself.

Paolo