linux-kernel - Re: [PATCH v3 09/19] x86/cpu: Clear VMX feature flag if VMX is not fully enabled

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: <20191121210714.GB16617@linux.intel.com>
Date:   Thu, 21 Nov 2019 13:07:14 -0800
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Tony Luck <tony.luck@...el.com>,
        Tony W Wang-oc <TonyWWang-oc@...oxin.com>,
        Shuah Khan <shuah@...nel.org>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, linux-edac@...r.kernel.org,
        "linux-kselftest@...r.kernel.org, Jarkko Sakkinen" 
        <jarkko.sakkinen@...ux.intel.com>
Subject: Re: [PATCH v3 09/19] x86/cpu: Clear VMX feature flag if VMX is not
 fully enabled

On Thu, Nov 21, 2019 at 05:24:52PM +0100, Borislav Petkov wrote:
> On Mon, Nov 18, 2019 at 07:12:30PM -0800, Sean Christopherson wrote:
> > Now that the IA32_FEATURE_CONTROL MSR is guaranteed to be configured and
> > locked, clear the VMX capability flag if the IA32_FEATURE_CONTROL MSR is
> > not supported or if BIOS disabled VMX, i.e. locked IA32_FEATURE_CONTROL
> > and did not set the appropriate VMX enable bit.
> > 
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@...el.com>
> > ---
> >  arch/x86/kernel/cpu/feature_control.c | 28 ++++++++++++++++++++++++---
> >  1 file changed, 25 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/cpu/feature_control.c b/arch/x86/kernel/cpu/feature_control.c
> > index 33c9444dda52..2bd1a9e6021a 100644
> > --- a/arch/x86/kernel/cpu/feature_control.c
> > +++ b/arch/x86/kernel/cpu/feature_control.c
> > @@ -5,15 +5,26 @@
> >  #include <asm/msr-index.h>
> >  #include <asm/processor.h>
> >  
> > +#undef pr_fmt
> > +#define pr_fmt(fmt)	"x86/cpu: " fmt
> > +
> > +#define FEAT_CTL_UNSUPPORTED_MSG "IA32_FEATURE_CONTROL MSR unsupported on VMX capable CPU, suspected hardware or hypervisor issue.\n"
> > +
> >  void init_feature_control_msr(struct cpuinfo_x86 *c)
> >  {
> > +	bool tboot = tboot_enabled();
> >  	u64 msr;
> >  
> > -	if (rdmsrl_safe(MSR_IA32_FEATURE_CONTROL, &msr))
> > +	if (rdmsrl_safe(MSR_IA32_FEATURE_CONTROL, &msr)) {
> > +		if (cpu_has(c, X86_FEATURE_VMX)) {
> > +			pr_err_once(FEAT_CTL_UNSUPPORTED_MSG);
> > +			clear_cpu_cap(c, X86_FEATURE_VMX);
> > +		}
> >  		return;
> > +	}
> 
> Right, so this test: is this something that could happen on some
> configurations - i.e., the MSR is not there but VMX bit is set - or are
> you being too cautious here?

Probably being overly cautious.

> IOW, do you have any concrete use cases in mind (cloud provider can f*ck
> it up this way) or?

Yes, VMM somehow managing to break things.  Admittedly extremely unlikely
given how long IA32_FEATURE_CONTROL has been around.

> My angle is that if this is never going to happen, why even bother to
> print anything...

My thought was to add an equivalent of the WARN that fires when an MSR
access unexpectedly faults.  That's effectively what'd be happening, except
I used the safe variant to reduce the maintenance cost, e.g. so that the
RDMSR doesn't have to be conditioned on every possible feature.

What about a WARN_ON cpu_has?  That'd be more aligned with the unexpected
#GP on RDMSR behavior.

	if (rdmsrl_safe(...)) {
		if (WARN_ON_ONCE(cpu_has(c, X86_FEATURE_VMX)))
			clear_cpu_cap(c, X86_FEATURE_VMX);
		return;
	}

I'm also ok dropping it altogether, though from a KVM developer
perspective I wouldn't mind the extra sanity check :-)