Qemu SEV-ES guest support
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
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
@@ -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
@@ -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
@@ -29,6 +29,7 @@#define SEV_POLICY_SEV 0x20extern 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
PATCH v4 3/6 sev/i386: Allow AP booting under SEV-ES
In reply to Tom LendackyFrom: 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH v4 5/6 kvm/i386: Use a per-VM check for SMM capability
In reply to Tom LendackyFrom: 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
@@ -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
PATCH v4 4/6 sev/i386: Don't allow a system reset under an SEV-ES guest
In reply to Tom LendackyFrom: 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.
--- 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH v4 2/6 sev/i386: Require in-kernel irqchip support for SEV-ES guests
In reply to Tom LendackyFrom: 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
@@ -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
PATCH v4 6/6 sev/i386: Enable an SEV-ES guest based on SEV policy
In reply to Tom LendackyFrom: 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
@@ -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
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_INITioctl is used to initialize the guest instead of the standardKVM_SEV_INITioctl. The second is that before the SEV launch measurement is calculated, theLAUNCH_UPDATE_VMSASEV API is invoked for each vCPU that Qemu has created. Once theLAUNCH_UPDATE_VMSAAPI 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-v12Changes since v3:
- Use the QemuUUID structure for GUID definitions
- Use SEV-ES policy bit definition fromtarget/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 checkChanges since v2:
- Add in-kernel irqchip requirement for SEV-ES guestsChanges since v1:
- Fixed checkpatch.pl errors/warningsTom 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 policyaccel/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(-)
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: 029socket_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]
Paolo Bonzini
maintainerRe: [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest
In reply to Tom Lendackysoftmmu/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
Paolo Bonzini
maintainerQuoted 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_INITioctl is used to initialize the guest instead of the standardKVM_SEV_INITioctl. The second is that before the SEV launch measurement is calculated, theLAUNCH_UPDATE_VMSASEV API is invoked for each vCPU that Qemu has created. Once theLAUNCH_UPDATE_VMSAAPI 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-v12Changes since v3:
- Use the QemuUUID structure for GUID definitions
- Use SEV-ES policy bit definition fromtarget/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 checkChanges since v2:
- Add in-kernel irqchip requirement for SEV-ES guestsChanges since v1:
- Fixed checkpatch.pl errors/warningsTom 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 policyaccel/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
Re: [PATCH v4 4/6] sev/i386: Don't allow a system reset under an SEV-ES guest
In reply to Paolo BonziniQuoted 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
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
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,
TomQuoted 5 lines
Thanks,
Paolo
Paolo Bonzini
maintainerQuoted 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