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 for Android: free password hash cracker in your pocket

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

Message-ID: <9B4F1C6D-05C1-4CFF-ABCA-3314E695894E@nutanix.com>
Date: Tue, 13 May 2025 02:18:18 +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 2:08 PM, Sean Christopherson <seanjc@...gle.com> wrote:
> 
> !-------------------------------------------------------------------|
>  CAUTION: External Email
> 
> |-------------------------------------------------------------------!
> 
> 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