x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel
commit9a417b0fe0931b37edef12e39509f8122d16b987
authorDavid Woodhouse <dwmw@amazon.co.uk>
Tue, 30 Jan 2018 14:30:23 +0000 (30 14:30 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 7 Feb 2018 19:14:12 +0000 (7 11:14 -0800)
tree1a79407433509e330223c20dcc7a145edd9c7499
parent7aa1a170313397d18b0fd21c87ebf655baa47f78
x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

commit 7fcae1118f5fd44a862aa5c3525248e35ee67c3b

Despite the fact that all the other code there seems to be doing it, just
using set_cpu_cap() in early_intel_init() doesn't actually work.

For CPUs with PKU support, setup_pku() calls get_cpu_cap() after
c->c_init() has set those feature bits. That resets those bits back to what
was queried from the hardware.

Turning the bits off for bad microcode is easy to fix. That can just use
setup_clear_cpu_cap() to force them off for all CPUs.

I was less keen on forcing the feature bits *on* that way, just in case
of inconsistencies. I appreciate that the kernel is going to get this
utterly wrong if CPU features are not consistent, because it has already
applied alternatives by the time secondary CPUs are brought up.

But at least if setup_force_cpu_cap() isn't being used, we might have a
chance of *detecting* the lack of the corresponding bit and either
panicking or refusing to bring the offending CPU online.

So ensure that the appropriate feature bits are set within get_cpu_cap()
regardless of how many extra times it's called.

Fixes: 2961298e ("x86/cpufeatures: Clean up Spectre v2 related CPUID flags")
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: karahmed@amazon.de
Cc: peterz@infradead.org
Cc: bp@alien8.de
Link: https://lkml.kernel.org/r/1517322623-15261-1-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/x86/kernel/cpu/common.c
arch/x86/kernel/cpu/intel.c