linux-kernel - Re: [PATCH] KVM: nVMX: Disallow access to vmcs12 fields that aren't supported by "hardware"

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aULA_VdN0gjjGJuF@google.com>
Date: Wed, 17 Dec 2025 06:41:01 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Xin Li <xin@...or.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Yosry Ahmed <yosry.ahmed@...ux.dev>
Subject: Re: [PATCH] KVM: nVMX: Disallow access to vmcs12 fields that aren't
 supported by "hardware"

On Tue, Dec 16, 2025, Xin Li wrote:
> > diff --git a/arch/x86/kvm/vmx/vmcs12.c b/arch/x86/kvm/vmx/vmcs12.c
> > index 4233b5ca9461..78eca9399975 100644
> > --- a/arch/x86/kvm/vmx/vmcs12.c
> > +++ b/arch/x86/kvm/vmx/vmcs12.c
> > @@ -9,7 +9,7 @@
> > FIELD(number, name), \
> > [ROL16(number##_HIGH, 6)] = VMCS12_OFFSET(name) + sizeof(u32)
> > 
> > -const unsigned short vmcs12_field_offsets[] = {
> > +const __initconst u16 supported_vmcs12_field_offsets[] = {
> 
> I initially misunderstood "supported" to mean the VMCS fields available at
> runtime.  I'm unsure if it's necessary to make its meaning more explicit.
> E.g., prefix with kvm_?

Oh, good point.  Ya, will do.

> > FIELD(VIRTUAL_PROCESSOR_ID, virtual_processor_id),
> > FIELD(POSTED_INTR_NV, posted_intr_nv),
> > FIELD(GUEST_ES_SELECTOR, guest_es_selector),
> > @@ -158,4 +158,55 @@ const unsigned short vmcs12_field_offsets[] = {
> > FIELD(HOST_SSP, host_ssp),
> > FIELD(HOST_INTR_SSP_TABLE, host_ssp_tbl),
> > };
> > -const unsigned int nr_vmcs12_fields = ARRAY_SIZE(vmcs12_field_offsets);
> > +
> > +u16 vmcs12_field_offsets[ARRAY_SIZE(supported_vmcs12_field_offsets)] __ro_after_init;
> > +unsigned int nr_vmcs12_fields __ro_after_init;
> > +
> > +#define VMCS12_CASE64(enc) case enc##_HIGH: case enc
> > +
> > +static __init bool cpu_has_vmcs12_field(unsigned int idx)
> > +{
> > + switch (VMCS12_IDX_TO_ENC(idx)) {
> > + case VIRTUAL_PROCESSOR_ID: return cpu_has_vmx_vpid();
> > + case POSTED_INTR_NV: return cpu_has_vmx_posted_intr();
> > + VMCS12_CASE64(TSC_MULTIPLIER): return cpu_has_vmx_tsc_scaling();
> > + VMCS12_CASE64(VIRTUAL_APIC_PAGE_ADDR): return cpu_has_vmx_tpr_shadow();
> > + VMCS12_CASE64(APIC_ACCESS_ADDR): return cpu_has_vmx_virtualize_apic_accesses();
> > + VMCS12_CASE64(POSTED_INTR_DESC_ADDR): return cpu_has_vmx_posted_intr();
> > + VMCS12_CASE64(VM_FUNCTION_CONTROL): return cpu_has_vmx_vmfunc();
> > + VMCS12_CASE64(EPT_POINTER): return cpu_has_vmx_ept();
> > + VMCS12_CASE64(EPTP_LIST_ADDRESS): return cpu_has_vmx_vmfunc();
> > + VMCS12_CASE64(XSS_EXIT_BITMAP): return cpu_has_vmx_xsaves();
> > + VMCS12_CASE64(ENCLS_EXITING_BITMAP): return cpu_has_vmx_encls_vmexit();
> > + VMCS12_CASE64(GUEST_IA32_PERF_GLOBAL_CTRL): return cpu_has_load_perf_global_ctrl();
> > + VMCS12_CASE64(HOST_IA32_PERF_GLOBAL_CTRL): return cpu_has_load_perf_global_ctrl();
> 
> Combine the above 2 cases?
> 
> > + case TPR_THRESHOLD: return cpu_has_vmx_tpr_shadow();
> > + case SECONDARY_VM_EXEC_CONTROL: return cpu_has_secondary_exec_ctrls();
> > + case GUEST_S_CET: return cpu_has_load_cet_ctrl();
> > + case GUEST_SSP: return cpu_has_load_cet_ctrl();
> > + case GUEST_INTR_SSP_TABLE: return cpu_has_load_cet_ctrl();
> > + case HOST_S_CET: return cpu_has_load_cet_ctrl();
> > + case HOST_SSP: return cpu_has_load_cet_ctrl();
> > + case HOST_INTR_SSP_TABLE: return cpu_has_load_cet_ctrl();
> 
> Combine all CET cases?

Yeah, will do.  I was on the fence as to whether it would be a net positive to
combine them.

Thanks!