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@xxxxxxxxx>
> > ---
> > 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 :-)
