V8 more sampling fun 0

From: mark gross <[email protected]>
Subject: [PATCH 1/4] x86/cpu: Add stepping field to x86_cpu_id structure

Quoted 2 lines · speck for mark gross

From: mark gross <[email protected]>
Subject: [PATCH 1/4] x86/cpu: Add stepping field to x86_cpu_id structure

s/stepping/steppings/

From: mark gross <[email protected]>
Subject: [PATCH 2/4] x86/cpu: clean up cpu_matches

Quoted 2 lines · speck for mark gross

From: mark gross <[email protected]>
Subject: [PATCH 2/4] x86/cpu: clean up cpu_matches

Vague subject, how about

x86/cpu: Add 'table' argument to cpu_matches()

Quoted 7 lines · speck for Josh Poimboeuf

Quoted 2 lines · speck for mark gross

From: mark gross <[email protected]>
Subject: [PATCH 2/4] x86/cpu: clean up cpu_matches

Vague subject, how about

x86/cpu: Add 'table' argument to cpu_matches()

Fixed, below final result:

---
From: Mark Gross <[email protected]>
Date: Thu, 16 Apr 2020 17:32:42 +0200
Subject: [PATCH] x86/cpu: Add 'table' argument to cpu_matches()

To make cpu_matches() reusable for other matching tables, have it take a x86_cpu_id table as an argument.

[ bp: Flip arguments order. ]

Signed-off-by Mark Gross <[email protected]>

Signed-off-by Borislav Petkov <[email protected]>

---
 arch/x86/kernel/cpu/common.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

arch/x86/kernel/cpu/common.c +14 -11

index bed0cb83fe24..1131ae032bf2 100644
@@ -1075,9 +1075,9 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
 	{}
 };
 
-static bool __init cpu_matches(unsigned long which)
+static bool __init cpu_matches(const struct x86_cpu_id *table, unsigned long which)
 {
-	const struct x86_cpu_id *m = x86_match_cpu(cpu_vuln_whitelist);
+	const struct x86_cpu_id *m = x86_match_cpu(table);
 
 	return m && !!(m->driver_data & which);
 }

@@ -1097,31 +1097,34 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	u64 ia32_cap = x86_read_arch_cap_msr();
 
 	/* Set ITLB_MULTIHIT bug if cpu is not in the whitelist and not mitigated */
-	if (!cpu_matches(NO_ITLB_MULTIHIT) && !(ia32_cap & ARCH_CAP_PSCHANGE_MC_NO))
+	if (!cpu_matches(cpu_vuln_whitelist, NO_ITLB_MULTIHIT) &&
+	    !(ia32_cap & ARCH_CAP_PSCHANGE_MC_NO))
 		setup_force_cpu_bug(X86_BUG_ITLB_MULTIHIT);
 
-	if (cpu_matches(NO_SPECULATION))
+	if (cpu_matches(cpu_vuln_whitelist, NO_SPECULATION))
 		return;
 
 	setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
 
-	if (!cpu_matches(NO_SPECTRE_V2))
+	if (!cpu_matches(cpu_vuln_whitelist, NO_SPECTRE_V2))
 		setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
 
-	if (!cpu_matches(NO_SSB) && !(ia32_cap & ARCH_CAP_SSB_NO) &&
+	if (!cpu_matches(cpu_vuln_whitelist, NO_SSB) &&
+	    !(ia32_cap & ARCH_CAP_SSB_NO) &&
 	   !cpu_has(c, X86_FEATURE_AMD_SSB_NO))
 		setup_force_cpu_bug(X86_BUG_SPEC_STORE_BYPASS);
 
 	if (ia32_cap & ARCH_CAP_IBRS_ALL)
 		setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
 
-	if (!cpu_matches(NO_MDS) && !(ia32_cap & ARCH_CAP_MDS_NO)) {
+	if (!cpu_matches(cpu_vuln_whitelist, NO_MDS) &&
+	    !(ia32_cap & ARCH_CAP_MDS_NO)) {
 		setup_force_cpu_bug(X86_BUG_MDS);
-		if (cpu_matches(MSBDS_ONLY))
+		if (cpu_matches(cpu_vuln_whitelist, MSBDS_ONLY))
 			setup_force_cpu_bug(X86_BUG_MSBDS_ONLY);
 	}
 
-	if (!cpu_matches(NO_SWAPGS))
+	if (!cpu_matches(cpu_vuln_whitelist, NO_SWAPGS))
 		setup_force_cpu_bug(X86_BUG_SWAPGS);
 
 	/*

@@ -1139,7 +1142,7 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	     (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))
 		setup_force_cpu_bug(X86_BUG_TAA);
 
-	if (cpu_matches(NO_MELTDOWN))
+	if (cpu_matches(cpu_vuln_whitelist, NO_MELTDOWN))
 		return;
 
 	/* Rogue Data Cache Load? No! */

@@ -1148,7 +1151,7 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 
 	setup_force_cpu_bug(X86_BUG_CPU_MELTDOWN);
 
-	if (cpu_matches(NO_L1TF))
+	if (cpu_matches(cpu_vuln_whitelist, NO_L1TF))
 		return;
 
 	setup_force_cpu_bug(X86_BUG_L1TF);

Signature · 4 lines

2.21.0

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

From: mark gross <[email protected]>
Subject: [PATCH 3/4] x86/speculation: Special Register Buffer Data Sampling
(SRBDS) mitigation control.

arch/x86/kernel/cpu/common.c +12 -0

@@ -1142,6 +1177,26 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	     (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))
 		setup_force_cpu_bug(X86_BUG_TAA);
 
+	/*
+	 * Some parts on the list don't have RDRAND or RDSEED. Make sure
+	 * they show as "Not affected".
+	 */
+	if (cpu_has(c, X86_FEATURE_RDRAND) || cpu_has(c, X86_FEATURE_RDSEED)) {
+		if (cpu_matches(SRBDS, cpu_vuln_blacklist)) {
+			/*
+			 * Parts in the blacklist that enumerate MDS_NO are
+			 * only vulnerable if TSX can be used.  To handle cases
+			 * where TSX gets fused off check to see if TSX is
+			 * fused off and thus not affected.
+			 */

Quoted 3 lines · speck for mark gross

From: mark gross <[email protected]>
Subject: [PATCH 3/4] x86/speculation: Special Register Buffer Data Sampling
(SRBDS) mitigation control.

Subjects don't need periods.

Review

Quoted 5 lines

(quoted diff) +5 -0

+static enum srbds_mitigations srbds_mitigation __ro_after_init = SRBDS_MITIGATION_FULL;
+static const char * const srbds_strings[] = {
+	[SRBDS_MITIGATION_OFF]		= "Vulnerable",
+	[SRBDS_MITIGATION_UCODE_NEEDED]	= "Vulnerable: No microcode",
+	[SRBDS_MITIGATION_FULL]		= "Mitigated: Microcode",

FWIW, this is at least the third time I've made this comment...

s/Mitigated/Mitigation/

Review

Quoted 1 line

(quoted diff) +1 -0

+	[SRBDS_MITIGATION_TSX_OFF]	= "Mitigated: TSX disabled",

s/Mitigated/Mitigation

When nitpicking the whitespace before, I think I completely missed the fact that this goto is extremely ugly. And there are a lot of unnecessary nested ifs. And the comment is redundant.

static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) {

arch/x86/kernel/cpu/common.c +11 -0

 	u64 ia32_cap = x86_read_arch_cap_msr();

@@ -1142,6 +1174,27 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	     (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))
 		setup_force_cpu_bug(X86_BUG_TAA);
 
+	/*
+	 * Some parts on the list don't have RDRAND or RDSEED. Make sure
+	 * they show as "Not affected".
+	 */
+	if (cpu_has(c, X86_FEATURE_RDRAND) || cpu_has(c, X86_FEATURE_RDSEED)) {
+		if (!cpu_matches(cpu_vuln_blacklist, SRBDS))
+			goto srbds_not_affected;
+
+		/*
+		 * Parts in the blacklist that enumerate MDS_NO are only
+		 * vulnerable if TSX can be used.  To handle cases where TSX

Quoted 23 lines · speck for Borislav Petkov

static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) {

arch/x86/kernel/cpu/common.c +16 -0

 	u64 ia32_cap = x86_read_arch_cap_msr();

@@ -1142,6 +1174,27 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	     (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))
 		setup_force_cpu_bug(X86_BUG_TAA);
 
+	/*
+	 * Some parts on the list don't have RDRAND or RDSEED. Make sure
+	 * they show as "Not affected".
+	 */
+	if (cpu_has(c, X86_FEATURE_RDRAND) || cpu_has(c, X86_FEATURE_RDSEED)) {
+		if (!cpu_matches(cpu_vuln_blacklist, SRBDS))
+			goto srbds_not_affected;
+
+		/*
+		 * Parts in the blacklist that enumerate MDS_NO are only
+		 * vulnerable if TSX can be used.  To handle cases where TSX
+		 * gets fused off check to see if TSX is fused off and thus not
+		 * affected.
+		 */
+		if ((ia32_cap & ARCH_CAP_MDS_NO) && tsx_fused_off(c, ia32_cap))
+			goto srbds_not_affected;

arch/x86/kernel/cpu/common.c static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) · line 1197

Quoted 5 lines

arch/x86/kernel/cpu/common.c +5 -0

+
+		setup_force_cpu_bug(X86_BUG_SRBDS);
+	}
+
+srbds_not_affected:

I still strongly dislike this and would much prefer my more compact non-goto version.

Otherwise everything looks good :-)

Signature · 1 line

Josh

Quoted 6 lines · speck for Josh Poimboeuf

Quoted 3 lines · speck for mark gross

From: mark gross <[email protected]>
Subject: [PATCH 3/4] x86/speculation: Special Register Buffer Data Sampling
(SRBDS) mitigation control.

Subjects don't need periods.

Fixed.

Quoted 9 lines

arch/x86/kernel/cpu/bugs.c static int __init tsx_async_abort_parse_cmdline(char *str)

Quoted 6 lines

arch/x86/kernel/cpu/bugs.c +5 -0

+static enum srbds_mitigations srbds_mitigation __ro_after_init = SRBDS_MITIGATION_FULL;
+static const char * const srbds_strings[] = {
+	[SRBDS_MITIGATION_OFF]		= "Vulnerable",
+	[SRBDS_MITIGATION_UCODE_NEEDED]	= "Vulnerable: No microcode",
+	[SRBDS_MITIGATION_FULL]		= "Mitigated: Microcode",

FWIW, this is at least the third time I've made this comment...

Quoted 5 lines

s/Mitigated/Mitigation/

Review

Quoted 1 line

(quoted diff) +1 -0

+	[SRBDS_MITIGATION_TSX_OFF]	= "Mitigated: TSX disabled",

s/Mitigated/Mitigation

Fixed.

Quoted 4 lines

When nitpicking the whitespace before, I think I completely missed the fact that this goto is extremely ugly. And there are a lot of unnecessary nested ifs. And the comment is redundant.

I've cleaned up that part a bit more, please have a look. Here's the whole thing:

---
From: Mark Gross <[email protected]>
Date: Thu, 16 Apr 2020 17:54:04 +0200
Subject: [PATCH] x86/speculation: Add Special Register Buffer Data Sampling
(SRBDS) mitigation controls

SRBDS is an MDS-like speculative side channel that can leak bits from the RNG across cores and threads. New microcode serializes the processor access during the execution of RDRAND and RDSEED. This ensures that the shared buffer is overwritten before it is released for reuse.

While it is present on all affected CPU models, the microcode mitigation is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the cases where TSX is not supported or has been disabled with TSX_CTRL.

The mitigation is activated by default on affected processors and it increases latency for RDRAND and RDSEED instructions. Among other effects this will reduce throughput from /dev/urandom.

* Enable administrator to configure the mitigation off when desired using either mitigations=off or srbds=off.

* Export vulnerability status via sysfs

* Rename file-scoped macros to apply for non-whitelist table initializations.

[ bp: Massage,
- s/VULNBL_INTEL_STEPPING/VULNBL_INTEL_STEPPINGS/g,
- do not read arch cap MSR a second time in tsx_fused_off() - just pass it in,
- flip check in cpu_set_bug_bits() to save an indentation level,
- reflow comments.
jpoimboe: s/Mitigated/Mitigation/ in user-visible strings ]

Signed-off-by Mark Gross <[email protected]>

Signed-off-by Borislav Petkov <[email protected]>

Reviewed-by Tony Luck <[email protected]>

Reviewed-by Pawan Gupta <[email protected]>

Reviewed-by Josh Poimboeuf <[email protected]>

Tested-by Neelima Krishnan <[email protected]>

---
 .../ABI/testing/sysfs-devices-system-cpu      |   1 +
 .../admin-guide/kernel-parameters.txt         |  20 ++++
 arch/x86/include/asm/cpufeatures.h            |   2 +
 arch/x86/include/asm/msr-index.h              |   4 +
 arch/x86/kernel/cpu/bugs.c                    | 107 ++++++++++++++++++
 arch/x86/kernel/cpu/common.c                  |  54 +++++++++
 arch/x86/kernel/cpu/cpu.h                     |   2 +
 drivers/base/cpu.c                            |   8 ++
 8 files changed, 198 insertions(+)

Documentation/ABI/testing/sysfs-devices-system-cpu +1 -0

index 2e0e3b45d02a..b39531a3c5bc 100644
@@ -492,6 +492,7 @@ What:		/sys/devices/system/cpu/vulnerabilities
 		/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
 		/sys/devices/system/cpu/vulnerabilities/l1tf
 		/sys/devices/system/cpu/vulnerabilities/mds
+		/sys/devices/system/cpu/vulnerabilities/srbds
 		/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
 		/sys/devices/system/cpu/vulnerabilities/itlb_multihit
 Date:		January 2018

Documentation/admin-guide/kernel-parameters.txt +20 -0

index f2a93c8679e8..f720463bd918 100644
@@ -4757,6 +4757,26 @@
 			the kernel will oops in either "warn" or "fatal"
 			mode.
 
+	srbds=		[X86,INTEL]
+			Control the Special Register Buffer Data Sampling
+			(SRBDS) mitigation.
+
+			Certain CPUs are vulnerable to an MDS-like
+			exploit which can leak bits from the random
+			number generator.
+
+			By default, this issue is mitigated by
+			microcode.  However, the microcode fix can cause
+			the RDRAND and RDSEED instructions to become
+			much slower.  Among other effects, this will
+			result in reduced throughput from /dev/urandom.
+
+			The microcode mitigation can be disabled with
+			the following option:
+
+			off:    Disable mitigation and remove
+				performance impact to RDRAND and RDSEED
+
 	srcutree.counter_wrap_check [KNL]
 			Specifies how frequently to check for
 			grace-period sequence counter wrap for the

arch/x86/include/asm/cpufeatures.h +2 -0

index db189945e9b0..02dabc9e77b0 100644
@@ -362,6 +362,7 @@
 #define X86_FEATURE_AVX512_4FMAPS	(18*32+ 3) /* AVX-512 Multiply Accumulation Single precision */
 #define X86_FEATURE_FSRM		(18*32+ 4) /* Fast Short Rep Mov */
 #define X86_FEATURE_AVX512_VP2INTERSECT (18*32+ 8) /* AVX-512 Intersect for D/Q */
+#define X86_FEATURE_SRBDS_CTRL		(18*32+ 9) /* "" SRBDS mitigation MSR available */
 #define X86_FEATURE_MD_CLEAR		(18*32+10) /* VERW clears CPU buffers */
 #define X86_FEATURE_TSX_FORCE_ABORT	(18*32+13) /* "" TSX_FORCE_ABORT */
 #define X86_FEATURE_PCONFIG		(18*32+18) /* Intel PCONFIG */

@@ -407,5 +408,6 @@
 #define X86_BUG_SWAPGS			X86_BUG(21) /* CPU is affected by speculation through SWAPGS */
 #define X86_BUG_TAA			X86_BUG(22) /* CPU is affected by TSX Async Abort(TAA) */
 #define X86_BUG_ITLB_MULTIHIT		X86_BUG(23) /* CPU may incur MCE during certain page attribute changes */
+#define X86_BUG_SRBDS			X86_BUG(24) /* CPU may leak RNG bits if not mitigated */
 
 #endif /* _ASM_X86_CPUFEATURES_H */

arch/x86/include/asm/msr-index.h +4 -0

index 12c9684d59ba..3efde600a674 100644
@@ -128,6 +128,10 @@
 #define TSX_CTRL_RTM_DISABLE		BIT(0)	/* Disable RTM feature */
 #define TSX_CTRL_CPUID_CLEAR		BIT(1)	/* Disable TSX enumeration */
 
+/* SRBDS support */
+#define MSR_IA32_MCU_OPT_CTRL		0x00000123
+#define RNGDS_MITG_DIS			BIT(0)
+
 #define MSR_IA32_SYSENTER_CS		0x00000174
 #define MSR_IA32_SYSENTER_ESP		0x00000175
 #define MSR_IA32_SYSENTER_EIP		0x00000176

arch/x86/kernel/cpu/bugs.c +107 -0

index ed54b3b21c39..95e066c8d45d 100644
@@ -41,6 +41,7 @@ static void __init l1tf_select_mitigation(void);
 static void __init mds_select_mitigation(void);
 static void __init mds_print_mitigation(void);
 static void __init taa_select_mitigation(void);
+static void __init srbds_select_mitigation(void);
 
 /* The base value of the SPEC_CTRL MSR that always has to be preserved. */
 u64 x86_spec_ctrl_base;

@@ -108,6 +109,7 @@ void __init check_bugs(void)
 	l1tf_select_mitigation();
 	mds_select_mitigation();
 	taa_select_mitigation();
+	srbds_select_mitigation();
 
 	/*
 	 * As MDS and TAA mitigations are inter-related, print MDS

@@ -397,6 +399,98 @@ static int __init tsx_async_abort_parse_cmdline(char *str)
 }
 early_param("tsx_async_abort", tsx_async_abort_parse_cmdline);
 
+#undef pr_fmt
+#define pr_fmt(fmt)	"SRBDS: " fmt
+
+enum srbds_mitigations {
+	SRBDS_MITIGATION_OFF,
+	SRBDS_MITIGATION_UCODE_NEEDED,
+	SRBDS_MITIGATION_FULL,
+	SRBDS_MITIGATION_TSX_OFF,
+	SRBDS_MITIGATION_HYPERVISOR,
+};
+
+static enum srbds_mitigations srbds_mitigation __ro_after_init = SRBDS_MITIGATION_FULL;
+
+static const char * const srbds_strings[] = {
+	[SRBDS_MITIGATION_OFF]		= "Vulnerable",
+	[SRBDS_MITIGATION_UCODE_NEEDED]	= "Vulnerable: No microcode",
+	[SRBDS_MITIGATION_FULL]		= "Mitigation: Microcode",
+	[SRBDS_MITIGATION_TSX_OFF]	= "Mitigation: TSX disabled",
+	[SRBDS_MITIGATION_HYPERVISOR]	= "Unknown: Dependent on hypervisor status",
+};
+
+static bool srbds_off;
+
+void update_srbds_msr(void)
+{
+	u64 mcu_ctrl;
+
+	if (!boot_cpu_has_bug(X86_BUG_SRBDS))
+		return;
+
+	if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+		return;
+
+	if (srbds_mitigation == SRBDS_MITIGATION_UCODE_NEEDED)
+		return;
+
+	rdmsrl(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
+
+	switch (srbds_mitigation) {
+	case SRBDS_MITIGATION_OFF:
+	case SRBDS_MITIGATION_TSX_OFF:
+		mcu_ctrl |= RNGDS_MITG_DIS;
+		break;
+	case SRBDS_MITIGATION_FULL:
+		mcu_ctrl &= ~RNGDS_MITG_DIS;
+		break;
+	default:
+		break;
+	}
+
+	wrmsrl(MSR_IA32_MCU_OPT_CTRL, mcu_ctrl);
+}
+
+static void __init srbds_select_mitigation(void)
+{
+	u64 ia32_cap;
+
+	if (!boot_cpu_has_bug(X86_BUG_SRBDS))
+		return;
+
+	/*
+	 * Check to see if this is one of the MDS_NO systems supporting
+	 * TSX that are only exposed to SRBDS when TSX is enabled.
+	 */
+	ia32_cap = x86_read_arch_cap_msr();
+	if ((ia32_cap & ARCH_CAP_MDS_NO) && !boot_cpu_has(X86_FEATURE_RTM))
+		srbds_mitigation = SRBDS_MITIGATION_TSX_OFF;
+	else if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
+		srbds_mitigation = SRBDS_MITIGATION_HYPERVISOR;
+	else if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL))
+		srbds_mitigation = SRBDS_MITIGATION_UCODE_NEEDED;
+	else if (cpu_mitigations_off() || srbds_off)
+		srbds_mitigation = SRBDS_MITIGATION_OFF;
+
+	update_srbds_msr();
+	pr_info("%s\n", srbds_strings[srbds_mitigation]);
+}
+
+static int __init srbds_parse_cmdline(char *str)
+{
+	if (!str)
+		return -EINVAL;
+
+	if (!boot_cpu_has_bug(X86_BUG_SRBDS))
+		return 0;
+
+	srbds_off = !strcmp(str, "off");
+
+	return 0;
+}
+early_param("srbds", srbds_parse_cmdline);
+
 #undef pr_fmt
 #define pr_fmt(fmt)     "Spectre V1 : " fmt
 

@@ -1528,6 +1622,11 @@ static char *ibpb_state(void)
 	return "";
 }
 
+static ssize_t srbds_show_state(char *buf)
+{
+	return sprintf(buf, "%s\n", srbds_strings[srbds_mitigation]);
+}
+
 static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr,
 			       char *buf, unsigned int bug)
 {

@@ -1572,6 +1671,9 @@ static ssize_t cpu_show_common(struct device *dev, struct device_attribute *attr
 	case X86_BUG_ITLB_MULTIHIT:
 		return itlb_multihit_show_state(buf);
 
+	case X86_BUG_SRBDS:
+		return srbds_show_state(buf);
+
 	default:
 		break;
 	}

@@ -1618,4 +1720,9 @@ ssize_t cpu_show_itlb_multihit(struct device *dev, struct device_attribute *attr
 {
 	return cpu_show_common(dev, attr, buf, X86_BUG_ITLB_MULTIHIT);
 }
+
+ssize_t cpu_show_srbds(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	return cpu_show_common(dev, attr, buf, X86_BUG_SRBDS);
+}
 #endif

arch/x86/kernel/cpu/common.c +54 -0

index 1131ae032bf2..dee4d14eb975 100644
@@ -1075,6 +1075,27 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
 	{}
 };
 
+#define VULNBL_INTEL_STEPPINGS(model, steppings, issues)		   \
+	X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6,		   \
+					    INTEL_FAM6_##model, steppings, \
+					    X86_FEATURE_ANY, issues)
+
+#define SRBDS		BIT(0)
+
+static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = {
+	VULNBL_INTEL_STEPPINGS(IVYBRIDGE,	X86_STEPPING_ANY,		SRBDS),
+	VULNBL_INTEL_STEPPINGS(HASWELL,		X86_STEPPING_ANY,		SRBDS),
+	VULNBL_INTEL_STEPPINGS(HASWELL_L,	X86_STEPPING_ANY,		SRBDS),
+	VULNBL_INTEL_STEPPINGS(HASWELL_G,	X86_STEPPING_ANY,		SRBDS),
+	VULNBL_INTEL_STEPPINGS(BROADWELL_G,	X86_STEPPING_ANY,		SRBDS),
+	VULNBL_INTEL_STEPPINGS(BROADWELL,	X86_STEPPING_ANY,		SRBDS),
+	VULNBL_INTEL_STEPPINGS(SKYLAKE_L,	X86_STEPPING_ANY,		SRBDS),
+	VULNBL_INTEL_STEPPINGS(SKYLAKE,		X86_STEPPING_ANY,		SRBDS),
+	VULNBL_INTEL_STEPPINGS(KABYLAKE_L,	X86_STEPPINGS(0x0, 0xC),	SRBDS),
+	VULNBL_INTEL_STEPPINGS(KABYLAKE,	X86_STEPPINGS(0x0, 0xD),	SRBDS),
+	{}
+};
+
 static bool __init cpu_matches(const struct x86_cpu_id *table, unsigned long which)
 {
 	const struct x86_cpu_id *m = x86_match_cpu(table);

@@ -1092,6 +1113,17 @@ u64 x86_read_arch_cap_msr(void)
 	return ia32_cap;
 }
 
+/*
+ * When running with up-to-date microcode TSX_CTRL is only enumerated on parts
+ * where TSX is fused on.  When running with microcode not supporting TSX_CTRL,
+ * check for RTM.
+ */
+static bool tsx_fused_off(struct cpuinfo_x86 *c, u64 ia32_cap)
+{
+	return !(ia32_cap & ARCH_CAP_TSX_CTRL_MSR) &&
+		 !cpu_has(c, X86_FEATURE_RTM);
+}
+
 static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 {
 	u64 ia32_cap = x86_read_arch_cap_msr();

@@ -1142,6 +1174,27 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	     (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))
 		setup_force_cpu_bug(X86_BUG_TAA);
 
+	/*
+	 * Some parts on the list don't have RDRAND or RDSEED. Make sure
+	 * they show as "Not affected".
+	 */
+	if (cpu_has(c, X86_FEATURE_RDRAND) || cpu_has(c, X86_FEATURE_RDSEED)) {
+		if (!cpu_matches(cpu_vuln_blacklist, SRBDS))
+			goto srbds_not_affected;
+
+		/*
+		 * Parts in the blacklist that enumerate MDS_NO are only
+		 * vulnerable if TSX can be used.  To handle cases where TSX
+		 * gets fused off check to see if TSX is fused off and thus not
+		 * affected.
+		 */
+		if ((ia32_cap & ARCH_CAP_MDS_NO) && tsx_fused_off(c, ia32_cap))
+			goto srbds_not_affected;
+
+		setup_force_cpu_bug(X86_BUG_SRBDS);
+	}
+
+srbds_not_affected:
 	if (cpu_matches(cpu_vuln_whitelist, NO_MELTDOWN))
 		return;
 

@@ -1594,6 +1647,7 @@ void identify_secondary_cpu(struct cpuinfo_x86 *c)
 	mtrr_ap_init();
 	validate_apic_and_package_id(c);
 	x86_spec_ctrl_setup_ap();
+	update_srbds_msr();
 }
 
 static __init int setup_noclflush(char *arg)

arch/x86/kernel/cpu/cpu.h +2 -0

index 37fdefd14f28..f3e2fc44dba0 100644
@@ -44,6 +44,8 @@ struct _tlb_table {
 extern const struct cpu_dev *const __x86_cpu_dev_start[],
 			    *const __x86_cpu_dev_end[];
 
+void update_srbds_msr(void);
+
 #ifdef CONFIG_CPU_SUP_INTEL
 enum tsx_ctrl_states {
 	TSX_CTRL_ENABLE,

drivers/base/cpu.c +8 -0

index 9a1c00fbbaef..d2136ab9b14a 100644
@@ -562,6 +562,12 @@ ssize_t __weak cpu_show_itlb_multihit(struct device *dev,
 	return sprintf(buf, "Not affected\n");
 }
 
+ssize_t __weak cpu_show_srbds(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	return sprintf(buf, "Not affected\n");
+}
+
 static DEVICE_ATTR(meltdown, 0444, cpu_show_meltdown, NULL);
 static DEVICE_ATTR(spectre_v1, 0444, cpu_show_spectre_v1, NULL);
 static DEVICE_ATTR(spectre_v2, 0444, cpu_show_spectre_v2, NULL);

@@ -570,6 +576,7 @@ static DEVICE_ATTR(l1tf, 0444, cpu_show_l1tf, NULL);
 static DEVICE_ATTR(mds, 0444, cpu_show_mds, NULL);
 static DEVICE_ATTR(tsx_async_abort, 0444, cpu_show_tsx_async_abort, NULL);
 static DEVICE_ATTR(itlb_multihit, 0444, cpu_show_itlb_multihit, NULL);
+static DEVICE_ATTR(srbds, 0444, cpu_show_srbds, NULL);
 
 static struct attribute *cpu_root_vulnerabilities_attrs[] = {
 	&dev_attr_meltdown.attr,

@@ -580,6 +587,7 @@ static struct attribute *cpu_root_vulnerabilities_attrs[] = {
 	&dev_attr_mds.attr,
 	&dev_attr_tsx_async_abort.attr,
 	&dev_attr_itlb_multihit.attr,
+	&dev_attr_srbds.attr,
 	NULL
 };
 

Signature · 4 lines

2.21.0

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

On Thu, Apr 16, 2020 at 12:17:23PM -0500, speck for Josh Poimboeuf wrote:

While it is present on all affected CPU models, the microcode mitigation is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the cases where TSX is not supported or has been disabled with TSX_CTRL.

Quoted 5 lines · speck for Borislav Petkov

On Thu, Apr 16, 2020 at 12:17:23PM -0500, speck for Josh Poimboeuf wrote:

While it is present on all affected CPU models, the microcode mitigation is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the cases where TSX is not supported or has been disabled with TSX_CTRL.

If the CPU has does not expose TSX_CTRL and has FEATURE_RTM disabled (BIOS or fused off) then we declare it as non vulnerable.

If the CPU exposes TSX_CTRL then we declare it vulnerable and decide in the mitigation selection whether it is vulnerable or not depending on the RTM state. If RTM is off, we say: "Mitigation: TSX disabled".

IMO the whole tsx_fused_off() logic is pointless. It does not matter whether TSX got fused off or disabled in BIOS or disabled via TSX_CTRL. The CPU model is affected but the problem is mitigated because TSX is disabled.

Aside of that the tsx_fused_off() logic depends on the non-availability of TSX_CTRL. TSX_CTRL is available even on CPUs which enumerate TAA_NO, but I don't see any check for TAA_NO or BUG_TAA anywhere.

Is SBRDS on MDS_NO parts independent of TAA, i.e. does it solely depend on the fact that RTM is on?

Quoted 6 lines · speck for Thomas Gleixner

Aside of that the tsx_fused_off() logic depends on the non-availability of TSX_CTRL. TSX_CTRL is available even on CPUs which enumerate TAA_NO, but I don't see any check for TAA_NO or BUG_TAA anywhere.

Is SBRDS on MDS_NO parts independent of TAA, i.e. does it solely depend on the fact that RTM is on?

I had assumed there are no parts in the SRBDS blacklist with TAA_NO.

Quoted 10 lines · speck for Thomas Gleixner

Quoted 5 lines · speck for Borislav Petkov

On Thu, Apr 16, 2020 at 12:17:23PM -0500, speck for Josh Poimboeuf wrote:

While it is present on all affected CPU models, the microcode mitigation is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the cases where TSX is not supported or has been disabled with TSX_CTRL.

If the CPU has does not expose TSX_CTRL and has FEATURE_RTM disabled (BIOS or fused off) then we declare it as non vulnerable.

Quoted 8 lines

If the CPU exposes TSX_CTRL then we declare it vulnerable and decide in the mitigation selection whether it is vulnerable or not depending on the RTM state. If RTM is off, we say: "Mitigation: TSX disabled".

IMO the whole tsx_fused_off() logic is pointless. It does not matter whether TSX got fused off or disabled in BIOS or disabled via TSX_CTRL. The CPU model is affected but the problem is mitigated because TSX is disabled.

The idea is that if TSX is *permanently* off, there's no way to trigger the bug, regardless of how the user has things configured in BIOS or the kernel. So from the user's standpoint, the CPU is not affected, and never was, regardless of kernel/BIOS settings and microcode.

Is there not a way to distinguish "disabled in BIOS" from "permanently fused off"? If not, then yes we should just consider all of them "Mitigation: TSX disabled".

Quoted 3 lines · speck for mark gross

From: mark gross <[email protected]>
Subject: [PATCH 3/4] x86/speculation: Special Register Buffer Data Sampling
(SRBDS) mitigation control.

Subjects don't need periods.

arch/x86/kernel/cpu/bugs.c enum srbds_mitigations { · line 417

Quoted 5 lines

arch/x86/kernel/cpu/bugs.c +5 -0

+static enum srbds_mitigations srbds_mitigation __ro_after_init = SRBDS_MITIGATION_FULL;
+static const char * const srbds_strings[] = {
+	[SRBDS_MITIGATION_OFF]		= "Vulnerable",
+	[SRBDS_MITIGATION_UCODE_NEEDED]	= "Vulnerable: No microcode",
+	[SRBDS_MITIGATION_FULL]		= "Mitigated: Microcode",

FWIW, this is at least the third time I've made this comment...

s/Mitigated/Mitigation/

arch/x86/kernel/cpu/bugs.c enum srbds_mitigations { · line 418

Quoted 1 line

arch/x86/kernel/cpu/bugs.c +1 -0

+	[SRBDS_MITIGATION_TSX_OFF]	= "Mitigated: TSX disabled",

s/Mitigated/Mitigation

Quoted 16 lines

arch/x86/kernel/cpu/common.c +12 -0

@@ -1142,6 +1177,26 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	     (ia32_cap & ARCH_CAP_TSX_CTRL_MSR)))
 		setup_force_cpu_bug(X86_BUG_TAA);
 
+	/*
+	 * Some parts on the list don't have RDRAND or RDSEED. Make sure
+	 * they show as "Not affected".
+	 */
+	if (cpu_has(c, X86_FEATURE_RDRAND) || cpu_has(c, X86_FEATURE_RDSEED)) {
+		if (cpu_matches(SRBDS, cpu_vuln_blacklist)) {
+			/*
+			 * Parts in the blacklist that enumerate MDS_NO are
+			 * only vulnerable if TSX can be used.  To handle cases
+			 * where TSX gets fused off check to see if TSX is
+			 * fused off and thus not affected.
+			 */

arch/x86/kernel/cpu/common.c static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c) · line 1201

Quoted 10 lines

arch/x86/kernel/cpu/common.c +8 -0

+			if ((ia32_cap & ARCH_CAP_MDS_NO) && tsx_fused_off(c))
+				goto srbds_not_affected;
+
+			setup_force_cpu_bug(X86_BUG_SRBDS);
+		}
+	}
+
+srbds_not_affected:
 	if (cpu_matches(NO_MELTDOWN, cpu_vuln_whitelist))
 		return;

When nitpicking the whitespace before, I think I completely missed the fact that this goto is extremely ugly. And there are a lot of unnecessary nested ifs. And the comment is redundant.

How about something like this:

	/*
	 * Parts in the SRBDS blacklist that enumerate MDS_NO are only
	 * vulnerable if TSX isn't fused off.
	 */
	if (cpu_matches(SRBDS, cpu_vuln_blacklist) &&
	    (cpu_has(c, X86_FEATURE_RDRAND) || cpu_has(c, X86_FEATURE_RDSEED)) &&
	    (!(ia32_cap & ARCH_CAP_MDS_NO) || !tsx_fused_off(c)))
		setup_force_cpu_bug(X86_BUG_SRBDS);

(quoted diff) +6 -0

+The possible values contained in this file are:
+
+ ============================== =============================================
+ Not affected                   Processor not vulnerable
+ Vulnerable                     Processor vulnerable and mitigation disabled
+ Vulnerable: No microcode       Processor vulnerable and microcode is missing

Quoted 10 lines · speck for mark gross

(quoted diff) +10 -0

+The possible values contained in this file are:
+
+ ============================== =============================================
+ Not affected                   Processor not vulnerable
+ Vulnerable                     Processor vulnerable and mitigation disabled
+ Vulnerable: No microcode       Processor vulnerable and microcode is missing
+                                mitigation
+ Mitigated: Microcode           Processor is vulnerable and mitigation is in
+                                effect.
+ Not affected (TSX disabled)    Processor is only vulnerable when TSX is

Review

Quoted 6 lines

(quoted diff) +6 -0

+                                enabled while this system was booted with TSX
+                                disabled.
+ Unknown                        Running on virtual guest processor that is
+                                affected but with no way to know if host
+                                processor is mitigated or vulnerable.
+ ============================== =============================================

This doesn't match the code.

Quoted 11 lines · speck for Josh Poimboeuf

Quoted 10 lines · speck for mark gross

(quoted diff) +10 -0

+The possible values contained in this file are:
+
+ ============================== =============================================
+ Not affected                   Processor not vulnerable
+ Vulnerable                     Processor vulnerable and mitigation disabled
+ Vulnerable: No microcode       Processor vulnerable and microcode is missing
+                                mitigation
+ Mitigated: Microcode           Processor is vulnerable and mitigation is in
+                                effect.
+ Not affected (TSX disabled)    Processor is only vulnerable when TSX is

Quoted 8 lines

Review

Quoted 6 lines

(quoted diff) +6 -0

+                                enabled while this system was booted with TSX
+                                disabled.
+ Unknown                        Running on virtual guest processor that is
+                                affected but with no way to know if host
+                                processor is mitigated or vulnerable.
+ ============================== =============================================

This doesn't match the code.

How's that?

============================== =============================================

 Not affected                   Processor not vulnerable
 Vulnerable                     Processor vulnerable and mitigation disabled
 Vulnerable: No microcode       Processor vulnerable and microcode is missing

mitigation
Mitigation: Microcode Processor is vulnerable and mitigation is in
effect.
Mitigation: TSX disabled Processor is only vulnerable when TSX is
enabled while this system was booted with TSX disabled.
Unknown: Dependent on
hypervisor status Running on virtual guest processor that is
affected but with no way to know if host processor is mitigated or vulnerable.
============================== =============================================

Regards/Gruss,
Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

Quoted 11 lines · speck for Josh Poimboeuf

Quoted 10 lines · speck for mark gross

(quoted diff) +10 -0

+The possible values contained in this file are:
+
+ ============================== =============================================
+ Not affected                   Processor not vulnerable
+ Vulnerable                     Processor vulnerable and mitigation disabled
+ Vulnerable: No microcode       Processor vulnerable and microcode is missing
+                                mitigation
+ Mitigated: Microcode           Processor is vulnerable and mitigation is in
+                                effect.
+ Not affected (TSX disabled)    Processor is only vulnerable when TSX is

Quoted 8 lines

Review

Quoted 6 lines

(quoted diff) +6 -0

+                                enabled while this system was booted with TSX
+                                disabled.
+ Unknown                        Running on virtual guest processor that is
+                                affected but with no way to know if host
+                                processor is mitigated or vulnerable.
+ ============================== =============================================

This doesn't match the code.

How's that?

============================== =============================================

 Not affected                   Processor not vulnerable
 Vulnerable                     Processor vulnerable and mitigation disabled
 Vulnerable: No microcode       Processor vulnerable and microcode is missing

mitigation
Mitigation: Microcode Processor is vulnerable and mitigation is in
effect.
Mitigation: TSX disabled Processor is only vulnerable when TSX is
enabled while this system was booted with TSX disabled.
Unknown: Dependent on
hypervisor status Running on virtual guest processor that is
affected but with no way to know if host processor is mitigated or vulnerable.
============================== =============================================

Signature · 5 lines

Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
-- 

On Thu, Apr 16, 2020 at 07:49:14PM +0200, speck for Borislav Petkov wrote:
from your emails it looks like you are putting together the final version. I have recently (this morning) found out I need to add another family model to

the affected processor list. Do you have a branch I could use to make a follow up patch too? (or if you are cool with me adding it to my local version and dealing with any minor fix ups let me know)

Quoted 4 lines · speck for mark gross

On Thu, Apr 16, 2020 at 07:49:14PM +0200, speck for Borislav Petkov wrote:
from your emails it looks like you are putting together the final version. I have recently (this morning) found out I need to add another family model to

Sigh...

Quoted 3 lines

the affected processor list. Do you have a branch I could use to make a follow up patch too? (or if you are cool with me adding it to my local version and dealing with any minor fix ups let me know)

Can you please send delta patch on top of your v8?

Folks,

I've merged the V8 series with the polishing done by Borislav into the master branch (based on 5.7-rc2) of the speck git repository at:

cvs.ou.linutronix.de:linux/speck/linux

The commits are considered stable from now on. Any further tweaks need to go on top.

The stable branches linux-5.6.y, linux-5.4.y, linux-4.19.y and linux-4.14.y have been updated with backports. Kernels prior to 4.14 are left as an exercise to the members of the kernel necrophilia cult as usual.

A tarball with git bundles is attached.

The subject line of this mail is a reference to the following part of the documentation:

Executing RDRAND, RDSEED or EGETKEY will delay memory accesses from other logical processors that miss their core caches, with an impact similar to legacy locked cache-line-split accesses.

IOW, yet another DoS tool. Oh well...

Thanks,

tglx

Quoted 7 lines · speck for Thomas Gleixner

Folks,

I've merged the V8 series with the polishing done by Borislav into the master branch (based on 5.7-rc2) of the speck git repository at:

cvs.ou.linutronix.de:linux/speck/linux

Quoted 7 lines

The commits are considered stable from now on. Any further tweaks need to go on top.

The stable branches linux-5.6.y, linux-5.4.y, linux-4.19.y and linux-4.14.y have been updated with backports. Kernels prior to 4.14 are left as an exercise to the members of the kernel necrophilia cult as usual.

We have ran all these through the test cases I used in my development. They all pass.

FWIW I did backports from 4.14.y to 4.9 (easy) and 4.4 (needed to cherry pic an extra patch to make it work) These also pass testing.

Should I post them to this list or sit on them until disclosure?

Quoted 19 lines · speck for mark gross

Quoted 7 lines · speck for Thomas Gleixner

Folks,

I've merged the V8 series with the polishing done by Borislav into the master branch (based on 5.7-rc2) of the speck git repository at:

cvs.ou.linutronix.de:linux/speck/linux

Quoted 7 lines

The commits are considered stable from now on. Any further tweaks need to go on top.

The stable branches linux-5.6.y, linux-5.4.y, linux-4.19.y and linux-4.14.y have been updated with backports. Kernels prior to 4.14 are left as an exercise to the members of the kernel necrophilia cult as usual.

We have ran all these through the test cases I used in my development. They all pass.

Quoted 4 lines

FWIW I did backports from 4.14.y to 4.9 (easy) and 4.4 (needed to cherry pic an extra patch to make it work) These also pass testing.

Should I post them to this list or sit on them until disclosure?

Why wait?

Please post them, I would greatly appreciate them.

Review

Quoted 3 lines · speck for mark gross

(quoted diff) +3 -0

+Mitigation mechanism
+-------------------
+Intel will release microcode updates ...

So while we're on the subject and in case I haven't missed that
communication: is that microcode somewhere so that I can test my backports with it?

It is in https://github.com/otcshare/Intel-Restricted-2020-1-IPU

If you haven't already got access, talk to [email protected]