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: <49c7519cfaf0c73cf77ab650852cbc81a55c75f4.camel@amd.com>
Date: Tue, 13 May 2025 07:57:12 +0000
From: "Shah, Amit" <Amit.Shah@....com>
To: "jon@...anix.com" <jon@...anix.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>
CC: "x86@...nel.org" <x86@...nel.org>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "hpa@...or.com" <hpa@...or.com>,
	"mingo@...hat.com" <mingo@...hat.com>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "bp@...en8.de" <bp@...en8.de>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "pbonzini@...hat.com" <pbonzini@...hat.com>,
	"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 Tue, 2025-05-13 at 02:18 +0000, Jon Kohler wrote:
> 
> 
> > 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

Yea - I think (at least for AMD GMET) if the VMM adds the GMET CPUID
bit to the guest CPUID, it should be taken as 'enabled' by KVM.  No
need for a module param there..

		Amit