| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <BYAPR21MB16880F8B27E5BE8D5A2EB884D7F29@BYAPR21MB1688.namprd21.prod.outlook.com>
Date: Wed, 28 Dec 2022 18:14:27 +0000
From: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To: Tianyu Lan <ltykernel@...il.com>,
"luto@...nel.org" <luto@...nel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"seanjc@...gle.com" <seanjc@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"jgross@...e.com" <jgross@...e.com>,
Tianyu Lan <Tianyu.Lan@...rosoft.com>,
"kirill@...temov.name" <kirill@...temov.name>,
"jiangshan.ljs@...group.com" <jiangshan.ljs@...group.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"ashish.kalra@....com" <ashish.kalra@....com>,
"srutherford@...gle.com" <srutherford@...gle.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"anshuman.khandual@....com" <anshuman.khandual@....com>,
"pawan.kumar.gupta@...ux.intel.com"
<pawan.kumar.gupta@...ux.intel.com>,
"adrian.hunter@...el.com" <adrian.hunter@...el.com>,
"daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
"alexander.shishkin@...ux.intel.com"
<alexander.shishkin@...ux.intel.com>,
"sandipan.das@....com" <sandipan.das@....com>,
"ray.huang@....com" <ray.huang@....com>,
"brijesh.singh@....com" <brijesh.singh@....com>,
"michael.roth@....com" <michael.roth@....com>,
"thomas.lendacky@....com" <thomas.lendacky@....com>,
"venu.busireddy@...cle.com" <venu.busireddy@...cle.com>,
"sterritt@...gle.com" <sterritt@...gle.com>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"samitolvanen@...gle.com" <samitolvanen@...gle.com>,
"fenghua.yu@...el.com" <fenghua.yu@...el.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: RE: [RFC PATCH V2 13/18] x86/hyperv: Add smp support for sev-snp
guest
From: Tianyu Lan <ltykernel@...il.com> Sent: Friday, November 18, 2022 7:46 PM
>
> The wakeup_secondary_cpu callback was populated with wakeup_
> cpu_via_vmgexit() which doesn't work for Hyper-V. Override it
> with Hyper-V specific hook which uses HVCALL_START_VIRTUAL_
> PROCESSOR hvcall to start AP with vmsa data structure.
>
> Signed-off-by: Tianyu Lan <tiala@...rosoft.com>
> ---
> arch/x86/include/asm/sev.h | 13 +++
> arch/x86/include/asm/svm.h | 55 ++++++++++-
> arch/x86/kernel/cpu/mshyperv.c | 147 +++++++++++++++++++++++++++++-
> include/asm-generic/hyperv-tlfs.h | 18 ++++
> 4 files changed, 230 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index ebc271bb6d8e..e34aaf730220 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -86,6 +86,19 @@ extern bool handle_vc_boot_ghcb(struct pt_regs *regs);
>
> #define RMPADJUST_VMSA_PAGE_BIT BIT(16)
>
> +union sev_rmp_adjust {
> + u64 as_uint64;
> + struct {
> + unsigned long target_vmpl : 8;
> + unsigned long enable_read : 1;
> + unsigned long enable_write : 1;
> + unsigned long enable_user_execute : 1;
> + unsigned long enable_kernel_execute : 1;
> + unsigned long reserved1 : 4;
> + unsigned long vmsa : 1;
> + };
> +};
> +
> /* SNP Guest message request */
> struct snp_req_data {
> unsigned long req_gpa;
> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
> index 0361626841bc..fc54d3e7f817 100644
> --- a/arch/x86/include/asm/svm.h
> +++ b/arch/x86/include/asm/svm.h
> @@ -328,8 +328,61 @@ struct vmcb_save_area {
> u64 br_to;
> u64 last_excp_from;
> u64 last_excp_to;
> - u8 reserved_6[72];
> +
> + /*
> + * The following part of the save area is valid only for
> + * SEV-ES guests when referenced through the GHCB or for
> + * saving to the host save area.
> + */
It seems unexpected to add these SEV-ES specific fields to a structure
with a comment that says for legacy and SEV-MEM guests. There's already
a struct sev_es_save_area with a comment that says for SEV-ES and
SEV_SNP guests, and that struct seems to have most or all of what is being
added here. Hopefully there's a way to use struct sev_es_save_area,
perhaps with some minor tweaks if necessary.
> + u8 reserved_7[72];
> u32 spec_ctrl; /* Guest version of SPEC_CTRL at 0x2E0 */
> + u8 reserved_7b[4];
> + u32 pkru;
> + u8 reserved_7a[20];
> + u64 reserved_8; /* rax already available at 0x01f8 */
> + u64 rcx;
> + u64 rdx;
> + u64 rbx;
> + u64 reserved_9; /* rsp already available at 0x01d8 */
> + u64 rbp;
> + u64 rsi;
> + u64 rdi;
> + u64 r8;
> + u64 r9;
> + u64 r10;
> + u64 r11;
> + u64 r12;
> + u64 r13;
> + u64 r14;
> + u64 r15;
> + u8 reserved_10[16];
> + u64 sw_exit_code;
> + u64 sw_exit_info_1;
> + u64 sw_exit_info_2;
> + u64 sw_scratch;
> + union {
> + u64 sev_features;
> + struct {
> + u64 sev_feature_snp : 1;
> + u64 sev_feature_vtom : 1;
> + u64 sev_feature_reflectvc : 1;
> + u64 sev_feature_restrict_injection : 1;
> + u64 sev_feature_alternate_injection : 1;
> + u64 sev_feature_full_debug : 1;
> + u64 sev_feature_reserved1 : 1;
> + u64 sev_feature_snpbtb_isolation : 1;
> + u64 sev_feature_resrved2 : 56;
> + };
> + };
> + u64 vintr_ctrl;
> + u64 guest_error_code;
> + u64 virtual_tom;
> + u64 tlb_id;
> + u64 pcpu_id;
> + u64 event_inject;
> + u64 xcr0;
> + u8 valid_bitmap[16];
> + u64 x87_state_gpa;
> } __packed;
>
> /* Save area definition for SEV-ES and SEV-SNP guests */
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index f0c97210c64a..b266f648e5cd 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -41,6 +41,10 @@
> #include <asm/realmode.h>
> #include <asm/e820/api.h>
>
> +#define EN_SEV_SNP_PROCESSOR_INFO_ADDR 0x802000
> +#define HV_AP_INIT_GPAT_DEFAULT 0x0007040600070406ULL
> +#define HV_AP_SEGMENT_LIMIT 0xffffffff
The above three definitions would benefit from some comments explaining
what they are.
> +
> /* Is Linux running as the root partition? */
> bool hv_root_partition;
> struct ms_hyperv_info ms_hyperv;
> @@ -232,6 +236,136 @@ static void __init hv_smp_prepare_boot_cpu(void)
> #endif
> }
>
> +static u8 ap_start_input_arg[PAGE_SIZE] __bss_decrypted __aligned(PAGE_SIZE);
> +static u8 ap_start_stack[PAGE_SIZE] __aligned(PAGE_SIZE);
> +
> +int hv_snp_boot_ap(int cpu, unsigned long start_ip)
> +{
> + struct vmcb_save_area *vmsa = (struct vmcb_save_area *)
> + __get_free_page(GFP_KERNEL | __GFP_ZERO);
> + struct desc_ptr gdtr;
> + u64 ret, retry = 5;
> + struct hv_enable_vp_vtl_input *enable_vtl_input;
> + struct hv_start_virtual_processor_input *start_vp_input;
> + union sev_rmp_adjust rmp_adjust;
> + void **arg;
> + unsigned long flags;
> +
> + *(void **)per_cpu_ptr(hyperv_pcpu_input_arg, cpu) = ap_start_input_arg;
I don't understand the above. It seems like the hyperv_pcpu_input_arg is being
set to the same static location for all APs. The static location gets overwritten in
hv_common_cpu_init(), so maybe everything works. But it seems like
ap_start_input_arg can just be used directly in this function without having to
update hyperv_pcpu_input_arg.
> +
> + hv_vp_index[cpu] = cpu;
The hv_vp_index[cpu] is also updated in hv_common_cpu_init(). Is there a
reason to initialize the value here? This code also assumes that Linux CPU
numbers and Hyper-V VP indices are the same. I've always observed that they
are indeed the same, but Hyper-V doesn't guarantee that. Hence we set the
value in hv_common_cpu_init() based on reading the per-CPU synthetic
register that contains the VP index.
> +
> + /* Prevent APs from entering busy calibration loop */
> + preset_lpj = lpj_fine;
I wonder if this is really needed. In a SEV-SNP guest that isn't running on
Hyper-V, how is this handled?
> +
> + /* Replace the provided real-mode start_ip */
> + start_ip = (unsigned long)secondary_startup_64_no_verify;
Any reason to update this global value? The starting IP is passed to Hyper-V
via the VMSA, so it doesn't seem like a global update is needed.
> +
> + native_store_gdt(&gdtr);
> +
> + vmsa->gdtr.base = gdtr.address;
> + vmsa->gdtr.limit = gdtr.size;
> +
> + asm volatile("movl %%es, %%eax;" : "=a" (vmsa->es.selector));
> + if (vmsa->es.selector) {
> + vmsa->es.base = 0;
> + vmsa->es.limit = HV_AP_SEGMENT_LIMIT;
> + vmsa->es.attrib = *(u16 *)(vmsa->gdtr.base + vmsa->es.selector + 5);
> + vmsa->es.attrib = (vmsa->es.attrib & 0xFF) | ((vmsa->es.attrib >> 4) & 0xF00);
> + }
The above "if" statement is repeated four times with different registers. Seems
like a helper function could easily encapsulate it, though not the "asm volatile"
statement.
> +
> + asm volatile("movl %%cs, %%eax;" : "=a" (vmsa->cs.selector));
> + if (vmsa->cs.selector) {
> + vmsa->cs.base = 0;
> + vmsa->cs.limit = HV_AP_SEGMENT_LIMIT;
> + vmsa->cs.attrib = *(u16 *)(vmsa->gdtr.base + vmsa->cs.selector + 5);
> + vmsa->cs.attrib = (vmsa->cs.attrib & 0xFF) | ((vmsa->cs.attrib >> 4) & 0xF00);
> + }
> +
> + asm volatile("movl %%ss, %%eax;" : "=a" (vmsa->ss.selector));
> + if (vmsa->ss.selector) {
> + vmsa->ss.base = 0;
> + vmsa->ss.limit = HV_AP_SEGMENT_LIMIT;
> + vmsa->ss.attrib = *(u16 *)(vmsa->gdtr.base + vmsa->ss.selector + 5);
> + vmsa->ss.attrib = (vmsa->ss.attrib & 0xFF) | ((vmsa->ss.attrib >> 4) & 0xF00);
> + }
> +
> + asm volatile("movl %%ds, %%eax;" : "=a" (vmsa->ds.selector));
> + if (vmsa->ds.selector) {
> + vmsa->ds.base = 0;
> + vmsa->ds.limit = HV_AP_SEGMENT_LIMIT;
> + vmsa->ds.attrib = *(u16 *)(vmsa->gdtr.base + vmsa->ds.selector + 5);
> + vmsa->ds.attrib = (vmsa->ds.attrib & 0xFF) | ((vmsa->ds.attrib >> 4) & 0xF00);
> + }
> +
> + vmsa->efer = native_read_msr(MSR_EFER);
> +
> + asm volatile("movq %%cr4, %%rax;" : "=a" (vmsa->cr4));
> + asm volatile("movq %%cr3, %%rax;" : "=a" (vmsa->cr3));
> + asm volatile("movq %%cr0, %%rax;" : "=a" (vmsa->cr0));
> +
> + vmsa->xcr0 = 1;
> + vmsa->g_pat = HV_AP_INIT_GPAT_DEFAULT;
> + vmsa->rip = (u64)start_ip;
> + vmsa->rsp = (u64)&ap_start_stack[PAGE_SIZE];
> +
> + vmsa->sev_feature_snp = 1;
> + vmsa->sev_feature_restrict_injection = 1;
> +
> + rmp_adjust.as_uint64 = 0;
> + rmp_adjust.target_vmpl = 1;
> + rmp_adjust.vmsa = 1;
> + ret = rmpadjust((unsigned long)vmsa, RMP_PG_SIZE_4K,
> + rmp_adjust.as_uint64);
> + if (ret != 0) {
> + pr_err("RMPADJUST(%llx) failed: %llx\n", (u64)vmsa, ret);
> + return ret;
> + }
> +
> + local_irq_save(flags);
> + arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg);
> + if (unlikely(!*arg)) {
> + ret = -ENOMEM;
> + goto done;
> + }
This code seems unnecessary. Just use ap_start_input_arg directly.
No need to disable interrupts.
> +
> + if (ms_hyperv.vtl != 0) {
> + enable_vtl_input = (struct hv_enable_vp_vtl_input *)*arg;
> + memset(enable_vtl_input, 0, sizeof(*enable_vtl_input));
> + enable_vtl_input->partitionid = -1;
> + enable_vtl_input->vpindex = cpu;
> + enable_vtl_input->targetvtl = ms_hyperv.vtl;
> + *(u64 *)&enable_vtl_input->context[0] = __pa(vmsa) | 1;
> +
> + ret = hv_do_hypercall(HVCALL_ENABLE_VP_VTL, enable_vtl_input, NULL);
> + if (ret != 0) {
Use hv_result_success() to test the hypercall result.
> + pr_err("HvCallEnableVpVtl failed: %llx\n", ret);
> + goto done;
> + }
> + }
> +
> + start_vp_input = (struct hv_start_virtual_processor_input *)*arg;
> + memset(start_vp_input, 0, sizeof(*start_vp_input));
> + start_vp_input->partitionid = -1;
> + start_vp_input->vpindex = cpu;
> + start_vp_input->targetvtl = ms_hyperv.vtl;
> + *(u64 *)&start_vp_input->context[0] = __pa(vmsa) | 1;
> +
> + do {
> + ret = hv_do_hypercall(HVCALL_START_VIRTUAL_PROCESSOR,
> + start_vp_input, NULL);
> + } while (ret == HV_STATUS_TIME_OUT && retry--);
Use hv_result() to check for HV_STATUS_TIME_OUT.
> +
> + if (ret != 0) {
Use hv_result_success().
> + pr_err("HvCallStartVirtualProcessor failed: %llx\n", ret);
> + goto done;
> + }
> +
> +done:
> + local_irq_restore(flags);
The entry to this function allocates a page for the VMSA. Does
that page ever get freed?
> + return ret;
> +}
> +
> static void __init hv_smp_prepare_cpus(unsigned int max_cpus)
> {
> #ifdef CONFIG_X86_64
> @@ -241,6 +375,16 @@ static void __init hv_smp_prepare_cpus(unsigned int max_cpus)
>
> native_smp_prepare_cpus(max_cpus);
>
> + /*
> + * Override wakeup_secondary_cpu callback for SEV-SNP
> + * enlightened guest.
> + */
> + if (hv_isolation_type_en_snp())
> + apic->wakeup_secondary_cpu = hv_snp_boot_ap;
> +
> + if (!hv_root_partition)
> + return;
> +
> #ifdef CONFIG_X86_64
> for_each_present_cpu(i) {
> if (i == 0)
> @@ -489,8 +633,7 @@ static void __init ms_hyperv_init_platform(void)
>
> # ifdef CONFIG_SMP
> smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
> - if (hv_root_partition)
> - smp_ops.smp_prepare_cpus = hv_smp_prepare_cpus;
> + smp_ops.smp_prepare_cpus = hv_smp_prepare_cpus;
> # endif
>
> /*
> diff --git a/include/asm-generic/hyperv-tlfs.h b/include/asm-generic/hyperv-tlfs.h
> index 6e2a090e2649..7072adbf5540 100644
> --- a/include/asm-generic/hyperv-tlfs.h
> +++ b/include/asm-generic/hyperv-tlfs.h
> @@ -139,6 +139,7 @@ struct ms_hyperv_tsc_page {
> #define HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST 0x0003
> #define HVCALL_NOTIFY_LONG_SPIN_WAIT 0x0008
> #define HVCALL_SEND_IPI 0x000b
> +#define HVCALL_ENABLE_VP_VTL 0x000f
> #define HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX 0x0013
> #define HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX 0x0014
> #define HVCALL_SEND_IPI_EX 0x0015
> @@ -156,6 +157,7 @@ struct ms_hyperv_tsc_page {
> #define HVCALL_MAP_DEVICE_INTERRUPT 0x007c
> #define HVCALL_UNMAP_DEVICE_INTERRUPT 0x007d
> #define HVCALL_RETARGET_INTERRUPT 0x007e
> +#define HVCALL_START_VIRTUAL_PROCESSOR 0x0099
> #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_SPACE 0x00af
> #define HVCALL_FLUSH_GUEST_PHYSICAL_ADDRESS_LIST 0x00b0
> #define HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY 0x00db
> @@ -763,6 +765,22 @@ struct hv_input_unmap_device_interrupt {
> struct hv_interrupt_entry interrupt_entry;
> } __packed;
>
> +struct hv_enable_vp_vtl_input {
> + u64 partitionid;
> + u32 vpindex;
> + u8 targetvtl;
> + u8 padding[3];
> + u8 context[0xe0];
It looks like the 0xe0 comes from the Hyper-V TLFS, but your
code is doing something different -- it's setting the VMSA address
instead of putting the context values inline.
> +} __packed;
> +
> +struct hv_start_virtual_processor_input {
> + u64 partitionid;
> + u32 vpindex;
> + u8 targetvtl;
> + u8 padding[3];
> + u8 context[0xe0];
Same here.
> +} __packed;
> +
> #define HV_SOURCE_SHADOW_NONE 0x0
> #define HV_SOURCE_SHADOW_BRIDGE_BUS_RANGE 0x1
>
> --
> 2.25.1
Powered by blists - more mailing lists