Re: [PATCH v4 6/7] x86/cpufeature: Blacklist SPEC_CTRL on early Spectre v2 microcodes

[David Woodhouse]

On Thu, 2018-01-25 at 12:34 +0100, Thomas Gleixner wrote:
> 
> This stuff is really a master piece of trainwreck engineering.
> 
> So yeah, whatever we do we end up with a proper mess. Lets go for a
> blacklist and hope that we'll have something which holds at some
> foreseeable day in the future.
> 
> The other concern I have is IBRS vs. IBPB. Are we sufficiently sure that
> IBPB is working on those IBRS blacklisted ucode revisions? Or should we
> just play safe and not touch any of this at all when we detect a
> blacklisted one?

That isn't sufficiently clear to me. I've changed it back to blacklist
*everything* for now, to be safe. If at any point Intel want to get
their act together and give us coherent information to the contrary, we
can change to separate IBPB/IBRS blacklists.

> Given the close to 0 trust in Intels change management and QA, I rather
> keep my hands from everything which was ever mentioned in any document as
> broken. I hope we have a collection of those PDFs stored at a safe place.

$ ls microcode-update-guidance-2018012*
microcode-update-guidance-20180122.pdf
microcode-update-guidance-20180123.pdf
microcode-update-guidance-20180124.pdf


Here's what I have now. I'm happy enough with this, so the main thing
I'm looking for is an ack from Alan for patch #5 of the series, if I've
got that sufficiently correct now.

From ad16c9a9f459a91c0980a2c7fde41640b6c04524 Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw@xxxxxxxxxxxx>
Date: Wed, 24 Jan 2018 15:54:41 +0000
Subject: [PATCH 06/18] x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early
ÂSpectre v2 microcodes

This doesn't refuse to load the affected microcodes; it just refuses to
use the Spectre v2 mitigation features if they're detected, by clearing
the appropriate feature bits.

The AMD CPUID bits are handled here too, because hypervisors *may* have
been exposing those bits even on Intel chips, for fine-grained control
of what's available.

It is non-trivial to use x86_match_cpu() for this table because that
doesn't handle steppings. And the approach taken in commit bd9240a18
almost made me lose my lunch.

Signed-off-by: David Woodhouse <dwmw@xxxxxxxxxxxx>
Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
Âarch/x86/kernel/cpu/intel.c | 66 +++++++++++++++++++++++++++++++++++++++++++++
Â1 file changed, 66 insertions(+)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index b720dac..125b65f 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -102,6 +102,59 @@ static void probe_xeon_phi_r3mwait(struct cpuinfo_x86 *c)
Â		ELF_HWCAP2 |= HWCAP2_RING3MWAIT;
Â}
Â
+/*
+ * Early microcode releases for the Spectre v2 mitigation were broken.
+ * Information taken from;
+ * â https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf
+ * â https://kb.vmware.com/s/article/52345
+ * â Microcode revisions observed in the wild
+ * â releasenote from 20180108 microcode release
+ */
+struct sku_microcode {
+	u8 model;
+	u8 stepping;
+	u32 microcode;
+};
+static const struct sku_microcode spectre_bad_microcodes[] = {
+	{ INTEL_FAM6_KABYLAKE_DESKTOP,	0x0B,	0x84 },
+	{ INTEL_FAM6_KABYLAKE_DESKTOP,	0x0A,	0x84 },
+	{ INTEL_FAM6_KABYLAKE_DESKTOP,	0x09,	0x84 },
+	{ INTEL_FAM6_KABYLAKE_MOBILE,	0x0A,	0x84 },
+	{ INTEL_FAM6_KABYLAKE_MOBILE,	0x09,	0x84 },
+	{ INTEL_FAM6_SKYLAKE_X,		0x03,	0x0100013e },
+	{ INTEL_FAM6_SKYLAKE_X,		0x04,	0x0200003c },
+	{ INTEL_FAM6_SKYLAKE_MOBILE,	0x03,	0xc2 },
+	{ INTEL_FAM6_SKYLAKE_DESKTOP,	0x03,	0xc2 },
+	{ INTEL_FAM6_BROADWELL_CORE,	0x04,	0x28 },
+	{ INTEL_FAM6_BROADWELL_GT3E,	0x01,	0x1b },
+	{ INTEL_FAM6_BROADWELL_XEON_D,	0x02,	0x14 },
+	{ INTEL_FAM6_BROADWELL_XEON_D,	0x03,	0x07000011 },
+	{ INTEL_FAM6_BROADWELL_X,	0x01,	0x0b000025 },
+	{ INTEL_FAM6_HASWELL_ULT,	0x01,	0x21 },
+	{ INTEL_FAM6_HASWELL_GT3E,	0x01,	0x18 },
+	{ INTEL_FAM6_HASWELL_CORE,	0x03,	0x23 },
+	{ INTEL_FAM6_HASWELL_X,		0x02,	0x3b },
+	{ INTEL_FAM6_HASWELL_X,		0x04,	0x10 },
+	{ INTEL_FAM6_IVYBRIDGE_X,	0x04,	0x42a },
+	/* Updated in the 20180108 release; blacklist until we know otherwise */
+	{ INTEL_FAM6_ATOM_GEMINI_LAKE,	0x01,	0x22 },
+	/* Observed in the wild */
+	{ INTEL_FAM6_SANDYBRIDGE_X,	0x06,	0x61b },
+	{ INTEL_FAM6_SANDYBRIDGE_X,	0x07,	0x712 },
+};
+
+static bool bad_spectre_microcode(struct cpuinfo_x86 *c)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(spectre_bad_microcodes); i++) {
+		if (c->x86_model == spectre_bad_microcodes[i].model &&
+		ÂÂÂÂc->x86_mask == spectre_bad_microcodes[i].stepping)
+			return (c->microcode <= spectre_bad_microcodes[i].microcode);
+	}
+	return false;
+}
+
Âstatic void early_init_intel(struct cpuinfo_x86 *c)
Â{
Â	u64 misc_enable;
@@ -122,6 +175,19 @@ static void early_init_intel(struct cpuinfo_x86 *c)
Â	if (c->x86 >= 6 && !cpu_has(c, X86_FEATURE_IA64))
Â		c->microcode = intel_get_microcode_revision();
Â
+	if ((cpu_has(c, X86_FEATURE_SPEC_CTRL) ||
+	ÂÂÂÂÂcpu_has(c, X86_FEATURE_STIBP) ||
+	ÂÂÂÂÂcpu_has(c, X86_FEATURE_AMD_SPEC_CTRL) ||
+	ÂÂÂÂÂcpu_has(c, X86_FEATURE_AMD_PRED_CMD) ||
+	ÂÂÂÂÂcpu_has(c, X86_FEATURE_AMD_STIBP)) && bad_spectre_microcode(c)) {
+		pr_warn("Intel Spectre v2 broken microcode detected; disabling SPEC_CTRL\n");
+		clear_cpu_cap(c, X86_FEATURE_SPEC_CTRL);
+		clear_cpu_cap(c, X86_FEATURE_STIBP);
+		clear_cpu_cap(c, X86_FEATURE_AMD_SPEC_CTRL);
+		clear_cpu_cap(c, X86_FEATURE_AMD_PRED_CMD);
+		clear_cpu_cap(c, X86_FEATURE_AMD_STIBP);
+	}
+
Â	/*
Â	Â* Atom erratum AAE44/AAF40/AAG38/AAH41:
Â	Â*
--Â
2.7.4

Attachment: smime.p7s
Description: S/MIME cryptographic signature