linux-kernel - Re: [RFC PATCH 03/18] KVM: x86: Add module parameter for Intel MBEC

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: <302DF79E-0B9B-450E-BB4F-DA88FDCD635F@nutanix.com>
Date: Tue, 23 Dec 2025 04:15:32 +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>
Subject: Re: [RFC PATCH 03/18] KVM: x86: Add module parameter for Intel MBEC



> On May 12, 2025, at 10:18 PM, Jon Kohler <jon@...anix.com> wrote:
> 
>> On May 12, 2025, at 2:08 PM, Sean Christopherson <seanjc@...gle.com> wrote:
>> 
>> On Thu, Mar 13, 2025, Jon Kohler wrote:
>>> Add 'enable_pt_guest_exec_control' module parameter to x86 code, with
>>> default value false.
>> 
>> ...
>> 
>>> +bool __read_mostly enable_pt_guest_exec_control;
>>> +EXPORT_SYMBOL_GPL(enable_pt_guest_exec_control);
>>> +module_param(enable_pt_guest_exec_control, bool, 0444);
>> 
>> The default value of a parameter doesn't prevent userspace from enabled the param.
>> I.e. the instant this patch lands, userspace can enable enable_pt_guest_exec_control,
>> which means MBEC needs to be 100% functional before this can be exposed to userspace.
>> 
>> The right way to do this is to simply omit the module param until KVM is ready to
>> let userspace enable the feature.
>> 
>> All that said, I don't see any reason to add a module param for this.  *KVM* isn't
>> using MBEC, the guest is using MBEC.  And unless host userspace is being extremely
>> careless with VMX MSRs, exposing MBEC to the guest will require additional VMM
>> enabling and/or user opt-in.
>> 
>> KVM provides module params to control features that KVM is using, generally when
>> there is no sane alternative to tell KVM not to use a particular feature, i.e.
>> when there is way for the user to disable a feature for testing/debug purposes.
>> 
>> Furthermore, how this series keys off the module param throughout KVM is completely
>> wrong.  The *only* input that ultimately matters is the control bit in vmcs12.
>> Whether or not KVM allows that bit to be set could be controlled by a module param,
>> but KVM shouldn't be looking at the module param outside of that particular check.
>> 
>> TL;DR: advertising and enabling MBEC should come along when KVM allows the bit to
>>      be set in vmcs12.
> 
> Gotcha, and I think this fact alone will drive a nice bit of cleanup thru
> the entire series. Will mop it up

Ack/done - all of this is cleaned up in favor of the nested.c based enablement