linux-kernel - Re: [RFC PATCH 17/18] KVM: VMX: Allow MBEC with EVMCS

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1F4D7E0A-B4DB-4E9B-B97D-FF4DF6A7902C@nutanix.com>
Date: Tue, 13 May 2025 02:01:46 +0000
From: Jon Kohler <jon@...anix.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "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>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        Vitaly Kuznetsov <vkuznets@...hat.com>
Subject: Re: [RFC PATCH 17/18] KVM: VMX: Allow MBEC with EVMCS



> On May 12, 2025, at 5:35 PM, Sean Christopherson <seanjc@...gle.com> wrote:
> 
> !-------------------------------------------------------------------|
>  CAUTION: External Email
> 
> |-------------------------------------------------------------------!
> 
> On Thu, Mar 13, 2025, Jon Kohler wrote:
>> Extend EVMCS1_SUPPORTED_2NDEXEC to understand MBEC enablement,
>> otherwise presenting both EVMCS and MBEC at the same time will disable
>> MBEC presentation into the guest.
> 
> A brief rundown on any relevant history of eVMCS support for MBEC would be
> appreciated, if there is any.

There isn’t any, but the broader theme of “make the commit/short log better” will
tidy this up, as I spent quite a lot of time on this eVMCS area trying to wrap my
head around that, I’ll codify that knowledge in the commit log

> 
>> Signed-off-by: Jon Kohler <jon@...anix.com>
>> 
>> ---
>> arch/x86/kvm/vmx/hyperv.c       | 5 ++++-
>> arch/x86/kvm/vmx/hyperv_evmcs.h | 1 +
>> 2 files changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/arch/x86/kvm/vmx/hyperv.c b/arch/x86/kvm/vmx/hyperv.c
>> index fab6a1ad98dc..941a29c9e667 100644
>> --- a/arch/x86/kvm/vmx/hyperv.c
>> +++ b/arch/x86/kvm/vmx/hyperv.c
>> @@ -138,7 +138,10 @@ void nested_evmcs_filter_control_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *
>> ctl_high &= evmcs_get_supported_ctls(EVMCS_EXEC_CTRL);
>> break;
>> case MSR_IA32_VMX_PROCBASED_CTLS2:
>> - ctl_high &= evmcs_get_supported_ctls(EVMCS_2NDEXEC);
>> + supported_ctrls = evmcs_get_supported_ctls(EVMCS_2NDEXEC);
>> + if (!vcpu->arch.pt_guest_exec_control)
>> + supported_ctrls &= ~SECONDARY_EXEC_MODE_BASED_EPT_EXEC;
> 
> No idea what you're trying to do, but I don't see how this is necessary in any
> capacity.

The eVMCS code has this logic to be able to “peel back” changes based
on runtime level enablement. I think with the broader changes to the series
suggested (moving control out of vcpu structure here), then this goes away.

I’ll seek to simplify this.

> 
>> + ctl_high &= supported_ctrls;
>> break;
>> case MSR_IA32_VMX_TRUE_PINBASED_CTLS:
>> case MSR_IA32_VMX_PINBASED_CTLS:
>> diff --git a/arch/x86/kvm/vmx/hyperv_evmcs.h b/arch/x86/kvm/vmx/hyperv_evmcs.h
>> index a543fccfc574..930429f376f9 100644
>> --- a/arch/x86/kvm/vmx/hyperv_evmcs.h
>> +++ b/arch/x86/kvm/vmx/hyperv_evmcs.h
>> @@ -87,6 +87,7 @@
>> SECONDARY_EXEC_PT_CONCEAL_VMX | \
>> SECONDARY_EXEC_BUS_LOCK_DETECTION | \
>> SECONDARY_EXEC_NOTIFY_VM_EXITING | \
>> + SECONDARY_EXEC_MODE_BASED_EPT_EXEC | \
>> SECONDARY_EXEC_ENCLS_EXITING)
>> 
>> #define EVMCS1_SUPPORTED_3RDEXEC (0ULL)
>> -- 
>> 2.43.0
>>