v4 more sampling fun 0

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

Intel uses the same family/model for several CPUs. Sometimes the stepping must be checked to tell them apart.

Note that to keep this patch simple the new field has been added at the end to avoid churn with all the pre-C99 initialized uses of this structure. Such legacy usage will result in a "0" value for the stepping field, hence X86_STEPPING_ANY is defined as "0".

Quoted 6 lines · speck for mark gross

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

Intel uses the same family/model for several CPUs. Sometimes the stepping must be checked to tell them apart.

Quoted 4 lines

Note that to keep this patch simple the new field has been added at the end to avoid churn with all the pre-C99 initialized uses of this structure. Such legacy usage will result in a "0" value for the stepping field, hence X86_STEPPING_ANY is defined as "0".

Are you sure about the "avoid churn" stuff? Can't you just fix up the X86_FEATURE_MATCH() #define to do that?

Also INTEL_CPU_FAM_ANY() already uses named identifiers, so you are ok with that usage. How many other places is this "open coded" that would need to be fixed up. Can't be more than 10-20, right?

include/linux/mod_devicetable.h struct x86_cpu_id { · line 669

Quoted 9 lines

include/linux/mod_devicetable.h +1 -0

@@ -665,6 +665,7 @@ struct x86_cpu_id {
 	__u16 model;
 	__u16 feature;	/* bit index */
 	kernel_ulong_t driver_data;
+	__u16 stepping;
 };

That just makes my eyes hurt, stepping really should be before driver_data.

The macros should be fixed up anyway to use named identifiers, no time like the present :)

And this, and the cleanups, can be done in public, like I thought we asked for before, right?

thanks,

greg k-h

Quoted 2 lines · speck for Greg KH

Are you sure about the "avoid churn" stuff? Can't you just fix up the X86_FEATURE_MATCH() #define to do that?

I wasn't confident about avoiding churn but I was hoping too. Yes, I am pretty sure I can fix up that macro.

Quoted 5 lines · speck for mark gross

Quoted 2 lines · speck for Greg KH

Are you sure about the "avoid churn" stuff? Can't you just fix up the X86_FEATURE_MATCH() #define to do that?

I wasn't confident about avoiding churn but I was hoping too. Yes, I am pretty sure I can fix up that macro.

My fault ... I thought it might be easier on the backport to all the stable and long term kernels if we kept this small at this stage. If upstream wants to cleanup all the users in a subsequent patch, then we can do that too.

Alternatively there is Thomas' suggestion to encode the range of steppings in the upper bits of driver_data and avoid touching this structure altogether.

Quoted 10 lines · speck for mark gross

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

Intel uses the same family/model for several CPUs. Sometimes the stepping must be checked to tell them apart.

Note that to keep this patch simple the new field has been added at the end to avoid churn with all the pre-C99 initialized uses of this structure. Such legacy usage will result in a "0" value for the stepping field, hence X86_STEPPING_ANY is defined as "0".

Are you sure about the "avoid churn" stuff? Can't you just fix up the X86_FEATURE_MATCH() #define to do that?

Also INTEL_CPU_FAM_ANY() already uses named identifiers, so you are ok with that usage. How many other places is this "open coded" that would need to be fixed up. Can't be more than 10-20, right?

include/linux/mod_devicetable.h struct x86_cpu_id { · line 669

Quoted 8 lines

include/linux/mod_devicetable.h +1 -0

@@ -665,6 +665,7 @@ struct x86_cpu_id {
 	__u16 model;
 	__u16 feature;	/* bit index */
 	kernel_ulong_t driver_data;
+	__u16 stepping;
 };

That just makes my eyes hurt, stepping really should be before driver_data.

The macros should be fixed up anyway to use named identifiers, no time like the present :)

And this, and the cleanups, can be done in public, like I thought we asked for before, right?

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

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.

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

Reviewed-by Tony Luck <[email protected]>

Reviewed-by Pawan Gupta <[email protected]>

Tested-by Neelima Krishnan <[email protected]>

---
 .../ABI/testing/sysfs-devices-system-cpu      |   1 +
 .../admin-guide/kernel-parameters.txt         |  11 ++
 arch/x86/include/asm/cpufeatures.h            |   2 +
 arch/x86/include/asm/msr-index.h              |   4 +
 arch/x86/kernel/cpu/bugs.c                    | 112 +++++++++++++++
 arch/x86/kernel/cpu/common.c                  | 128 +++++++++++-------
 arch/x86/kernel/cpu/cpu.h                     |  13 ++
 arch/x86/kernel/cpu/intel.c                   |   2 +
 arch/x86/kernel/cpu/match.c                   |   6 +-
 drivers/base/cpu.c                            |   8 ++
 include/linux/mod_devicetable.h               |   2 +-
 11 files changed, 236 insertions(+), 53 deletions(-)

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

index 2e0e3b45d02a..a890b3769335 100644

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

+
+			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

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

+
+	if (!boot_cpu_has_bug(X86_BUG_SRBDS)) {
+		srbds_mitigation = SRBDS_NOT_AFFECTED;
+		return;
+	}
+
+	if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL)) {
+		srbds_mitigation = SRBDS_MITIGATION_UCODE_NEEDED;
+		return;
+	}
+
+	if (boot_cpu_has_bug(X86_BUG_SRBDS)) {

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

+
+static int __init srbds_parse_cmdline(char *str)
+{
+	if (!str)
+		return -EINVAL;
+
+	if (!strcmp(str, "off"))
+		srbds_off = true;
+
+	return 0;
+}
+early_param("srbds", srbds_parse_cmdline);
+
 #undef pr_fmt
 #define pr_fmt(fmt)     "Spectre V1 : " fmt
 

@@ -1528,6 +1627,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 +1676,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;
 	}

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

+	return cpu_show_common(dev, attr, buf, X86_BUG_SRBDS);
+}
 #endif

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

@@ -44,7 +44,20 @@ struct _tlb_table {
 extern const struct cpu_dev *const __x86_cpu_dev_start[],
 			    *const __x86_cpu_dev_end[];
 

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

+void srbds_configure_mitigation(void);
+
 #ifdef CONFIG_CPU_SUP_INTEL
+
 enum tsx_ctrl_states {
 	TSX_CTRL_ENABLE,
 	TSX_CTRL_DISABLE,

arch/x86/kernel/cpu/intel.c +0 -0

index be82cd5841c3..1b083a2a415b 100644

From: mark gross <[email protected]>
Subject: [PATCH 3/3] x86/speculation: SRBDS vulnerability and mitigation
documentation

Add documentation for the SRBDS vulnerability and its mitigation.

Reviewed-by Tony Luck <[email protected]>

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

---
 Documentation/admin-guide/hw-vuln/index.rst   |   2 +
 .../special-register-buffer-data-sampling.rst | 150 ++++++++++++++++++
 2 files changed, 152 insertions(+)
 create mode 100644 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst

Documentation/admin-guide/hw-vuln/index.rst +2 -0

index 0795e3c2643f..99d5b3244ef9 100644
@@ -14,3 +14,5 @@ are configurable at compile, boot or run time.
    mds
    tsx_async_abort
    multihit.rst
+   special-register-buffer-data-sampling.rst
+

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +0 -0

new file mode 100644
index 000000000000..1fae5f455eb8

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +43 -0

+the special register reads that have a security expectation of privacy are:
+RDRAND, RDSEED and SGX EGETKEY.
+
+When RDRAND RDSEED and EGETKEY instructions are used the data is moved to the
+core through the special register mechanism that is susceptible to MDS attacks.
+
+Affected processors
+--------------------
+Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED and
+are vulnerable to MFBDS (Micro architectural Fill Buffer Data Sampling) variant
+of MDS (Micro architectural Data Sampling) or to the TAA (TSX Asynchronous
+Abort) when TSX is enabled,
+
+  =============  ============  ==========================
+  common name    Family_Model  Stepping
+  =============  ============  ==========================
+  Ivybridge      06_3AH        All
+
+  Haswell        06_3CH        All
+  Haswell_L      06_45H        All
+  Haswell_G      06_46H        All
+
+  Broadwell_G    06_47H        All
+  Broadwell      06_3DH        All
+
+  Skylake_L      06_4EH        All
+  Skylake        06_5EH        All
+
+  Kabylake_L     06_8EH        <=A
+  Kabylake_L     06_8EH        0xB only if TSX is enabled
+  Kabylake_L     06_8EH        0xC only if TSX is enabled
+
+  Kabylake       06_9EH        <=B
+  Kabylake       06_9EH        0xC only if TSX is enabled
+  Kabylake       06_9EH        0xD only if TSX is enabled
+  =============  ============  ==========================
+
+Related CVEs
+------------
+
+The following CVE entry is related to this SRBDS issue:
+
+    ==============  =====  =====================================

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +50 -0

+-------------------
+Intel will release microcode updates that modify the RDRAND, RDSEED, and
+EGETKEY instructions to overwrite secret special register data in the shared
+staging buffer before the secret data can be accessed by another logical
+processor.
+
+During execution of the RDRAND, RDSEED, or EGETKEY instruction, off-core
+accesses from other logical processors will be delayed until the special
+register read is complete and the secret data in the shared staging buffer is
+overwritten.
+
+This has three effects on performance:
+
+#. RDRAND, RDSEED, or EGETKEY instruction have higher latency.
+
+#. Executing RDRAND at the same time on multiple logical processors will be
+   serialized, resulting in an overall reduction in the maximum RDRAND
+   bandwidth.
+
+#. 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.
+
+Because of the performance impact of the mitigation, the microcode updates also
+provide an opt-out mechanism (RNGDS_MITG_DIS) to disable the mitigation for
+RDRAND and RDSEED instructions executed outside of Intel Software Guard
+Extensions (Intel SGX) enclaves. On logical processors that disable the
+mitigation using this opt-out mechanism, RDRAND and RDSEED do not take longer
+to execute and do not impact performance of sibling logical processors memory
+accesses. The opt-out mechanism does not affect Intel SGX enclaves (including
+execution of RDRAND or RDSEED inside of an enclave, as well as EGETKEY
+execution).
+
+IA32_MCU_OPT_CTRL MSR Definition
+--------------------------------
+Along with the mitigation for this issue, Intel added a new thread-scope
+IA32_MCU_OPT_CTRL MSR, (address 0x123). The presence of this MSR and
+RNGDS_MITG_DIS (bit 0) is enumerated by CPUID.(EAX=07H,ECX=0).EDX[SRBDS_CTRL =
+9]==1. This MSR is introduced through the microcode update.
+
+Setting IA32_MCU_OPT_CTRL[0] (RNGDS_MITG_DIS) to 1 for a logical processor
+disables the mitigation for RDRAND and RDSEED executed outside of an Intel SGX
+enclave on that logical processor. Opting out of the mitigation for a
+particular logical processor does not affect the RDRAND and RDSEED mitigations
+for other logical processors.
+
+Note that inside of an Intel SGX enclave, the mitigation is applied regardless
+of the value of RNGDS_MITG_DS.
+
+Mitigation control on the kernel command line

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +14 -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                      Processor is vulnerable and mitigation is in
+                                effect.
+ Not affected (TSX disabled)    Processor is only vulnerable when TSX is
+                                enabled while this system was booted with TSX
+                                disabled.
+ Unknown                        Running on virtual guest processor that is

Quoted 23 lines · speck for mark gross

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

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.

Quoted 4 lines

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

Reviewed-by Tony Luck <[email protected]>

Reviewed-by Pawan Gupta <[email protected]>

Tested-by Neelima Krishnan <[email protected]>

Sorry for being a little late to the review.

Quoted 20 lines

---
 .../ABI/testing/sysfs-devices-system-cpu      |   1 +
 .../admin-guide/kernel-parameters.txt         |  11 ++
 arch/x86/include/asm/cpufeatures.h            |   2 +
 arch/x86/include/asm/msr-index.h              |   4 +
 arch/x86/kernel/cpu/bugs.c                    | 112 +++++++++++++++
 arch/x86/kernel/cpu/common.c                  | 128 +++++++++++-------
 arch/x86/kernel/cpu/cpu.h                     |  13 ++
 arch/x86/kernel/cpu/intel.c                   |   2 +
 arch/x86/kernel/cpu/match.c                   |   6 +-
 drivers/base/cpu.c                            |   8 ++
 include/linux/mod_devicetable.h               |   2 +-
 11 files changed, 236 insertions(+), 53 deletions(-)

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

index 2e0e3b45d02a..a890b3769335 100644

Documentation/ABI/testing/sysfs-devices-system-cpu What: /sys/devices/system/cpu/vulnerabilities · line 495

Quoted 4 lines

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

@@ -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/special_register_data_sampling

That's not the actual name of the vulnerability. The file should match the actual name (or my personal preference, the "srbds" abbreviation).

Documentation/admin-guide/kernel-parameters.txt line 4662

Quoted 12 lines

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

 		/sys/devices/system/cpu/vulnerabilities/tsx_async_abort
 		/sys/devices/system/cpu/vulnerabilities/itlb_multihit
 Date:		January 2018

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

index c07815d230bc..71cf7e7eae45 100644
@@ -4659,6 +4659,17 @@
 	spia_pedr=
 	spia_peddr=
 
+	srbds=		[x86]

			[X86,INTEL]

(note the capital X for consistency with other entries and kernel-parameters.rst)

Documentation/admin-guide/kernel-parameters.txt line 4664

Quoted 2 lines

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

+			Special Register Buffer Data Sampling mitigation
+			control.

Control mitigation for the Special Register Buffer Data Sampling (SRBDS) mitigation.

Documentation/admin-guide/kernel-parameters.txt line 4668

Quoted 4 lines

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

+
+			On CPUs vulnerable to this issue and users impacted by
+			the mitigation slowing down RDRAND and RDSEED can
+			disable by setting this:

-ENOPARSE

How about:

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

Quoted 8 lines

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

+
+			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

Documentation/admin-guide/kernel-parameters.txt static int __init tsx_async_abort_parse_cmdline(char *str) · line 407

Quoted 9 lines

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

@@ -397,6 +399,103 @@ 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 __ro_after_init = SRBDS_MITIGATION_FULL;
+static const char * const srbds_strings[] = {
+	[SRBDS_NOT_AFFECTED]		= "Not affected",

I don't think the SRBDS_NOT_AFFECTED enum is needed.

The "Not affected" string is already printed by cpu_show_common().

And srbds_configure_mitigation() can just check for boot_cpu_has_bug(X86_BUG_SRBDS) instead of this enum value.

Documentation/admin-guide/kernel-parameters.txt static int __init tsx_async_abort_parse_cmdline(char *str) · line 417

Quoted 11 lines

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

+	[SRBDS_MITIGATION_OFF]		= "Vulnerable",
+	[SRBDS_MITIGATION_UCODE_NEEDED]	= "Vulnerable: no microcode",
+	[SRBDS_MITIGATION_FULL]		= "Mitigated",
+	[SRBDS_NOT_AFFECTED_TSX_OFF]	= "Not affected (TSX disabled)",
+	[SRBDS_HYPERVISOR]		= "Unknown",
+};
+
+static bool srbds_off;
+
+void srbds_configure_mitigation(void)

To me, "configure" sounds like it could be a software thing.

How about update_srbds_msr(), which is also more consistent with some of the other naming in the file.

Documentation/admin-guide/kernel-parameters.txt static int __init tsx_async_abort_parse_cmdline(char *str) · line 425

Quoted 9 lines

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

+static void __init srbds_select_mitigation(void)
+{
+	u64 ia32_cap;
+
+	if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
+		srbds_mitigation = SRBDS_HYPERVISOR;
+		return;
+	}

It's confusing that this comes before the X86_BUG_SRBDS check. Is that on purpose?

If so, I presume it doesn't have the intended effect, because if booting in a guest on a non-vulnerable CPU, srbds_mitigation will get set to SRBDS_HYPERVISOR, but the shown state will still be "Not affected" because of how cpu_show_common() checks for the bug at the beginning.

Quoted 12 lines

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

+
+	if (!boot_cpu_has_bug(X86_BUG_SRBDS)) {
+		srbds_mitigation = SRBDS_NOT_AFFECTED;
+		return;
+	}
+
+	if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL)) {
+		srbds_mitigation = SRBDS_MITIGATION_UCODE_NEEDED;
+		return;
+	}
+
+	if (boot_cpu_has_bug(X86_BUG_SRBDS)) {

Documentation/admin-guide/kernel-parameters.txt static int __init tsx_async_abort_parse_cmdline(char *str) · line 447

Quoted 10 lines

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

+		srbds_mitigation = SRBDS_MITIGATION_FULL;
+		/*
+		 * 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) {
+			if (!boot_cpu_has(X86_FEATURE_RTM))
+				srbds_mitigation = SRBDS_NOT_AFFECTED_TSX_OFF;
+		}

I wonder if this would be equivalent?

		if (!boot_cpu_has_bug(X86_BUG_MDS) && boot_cpu_has(X86_BUG_TAA) &&
		    !boot_cpu_has(X86_FEATURE_RTM))
		    	srbds_mitigation = SRBDS_NOT_AFFECTED_TSX_OFF;

Documentation/admin-guide/kernel-parameters.txt static int __init tsx_async_abort_parse_cmdline(char *str) · line 456

Quoted 10 lines

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

+	}
+
+	if (cpu_mitigations_off() || srbds_off) {
+		if (srbds_mitigation != SRBDS_NOT_AFFECTED_TSX_OFF)
+			srbds_mitigation = SRBDS_MITIGATION_OFF;
+	}
+
+	srbds_configure_mitigation();
+}

The other mitigations do a printk with the mitigation status here. Should we not do the same here?

Quoted 40 lines

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

+
+static int __init srbds_parse_cmdline(char *str)
+{
+	if (!str)
+		return -EINVAL;
+
+	if (!strcmp(str, "off"))
+		srbds_off = true;
+
+	return 0;
+}
+early_param("srbds", srbds_parse_cmdline);
+
 #undef pr_fmt
 #define pr_fmt(fmt)     "Spectre V1 : " fmt
 

@@ -1528,6 +1627,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 +1676,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;
 	}

Documentation/admin-guide/kernel-parameters.txt ssize_t cpu_show_itlb_multihit(struct device *dev, struct device_attribute *attr · line 1730

Quoted 6 lines

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

@@ -1618,4 +1725,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_special_register_data_sampling(struct device *dev, struct device_attribute *attr, char *buf)
+{

This function name can be renamed to match whatever the filename turns out to be:

cpu_show_srbds()

or

cpu_show_special_register_data_buffer_sampling()

Quoted 10 lines

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

+	return cpu_show_common(dev, attr, buf, X86_BUG_SRBDS);
+}
 #endif

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

@@ -44,7 +44,20 @@ struct _tlb_table {
 extern const struct cpu_dev *const __x86_cpu_dev_start[],
 			    *const __x86_cpu_dev_end[];
 

arch/x86/kernel/cpu/cpu.h struct _tlb_table { · line 56

Quoted 10 lines

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

+enum srbds_mitigations {
+	SRBDS_NOT_AFFECTED,
+	SRBDS_MITIGATION_OFF,
+	SRBDS_MITIGATION_UCODE_NEEDED,
+	SRBDS_MITIGATION_FULL,
+	SRBDS_NOT_AFFECTED_TSX_OFF,
+	SRBDS_HYPERVISOR,
+};
+
+extern __ro_after_init enum srbds_mitigations srbds_mitigation;

srbds_mitigation isn't used outside of bugs.c, so it can just be a static variable and the enum definition can live there as well.

Quoted 12 lines

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

+void srbds_configure_mitigation(void);
+
 #ifdef CONFIG_CPU_SUP_INTEL
+
 enum tsx_ctrl_states {
 	TSX_CTRL_ENABLE,
 	TSX_CTRL_DISABLE,

arch/x86/kernel/cpu/intel.c +0 -0

index be82cd5841c3..1b083a2a415b 100644

arch/x86/kernel/cpu/intel.c static void init_intel(struct cpuinfo_x86 *c) · line 689

Quoted 6 lines

arch/x86/kernel/cpu/intel.c +2 -0

@@ -684,6 +684,8 @@ static void init_intel(struct cpuinfo_x86 *c)
 		tsx_enable();
 	if (tsx_ctrl_state == TSX_CTRL_DISABLE)
 		tsx_disable();
+
+	srbds_configure_mitigation();
 }

I'm not sure this is the right place to call this. On the boot CPU, this gets called *before* the mitigation is selected, and then again from srbds_select_mitigation() itself.

Maybe it should instead be called from identify_secondary_cpu(), while keeping the existing call from srbds_select_mitigation() so the boot CPU also gets updated.

Quoted 32 lines · speck for mark gross

From: mark gross <[email protected]>
Subject: [PATCH 3/3] x86/speculation: SRBDS vulnerability and mitigation
documentation

Add documentation for the SRBDS vulnerability and its mitigation.

Reviewed-by Tony Luck <[email protected]>

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

---
 Documentation/admin-guide/hw-vuln/index.rst   |   2 +
 .../special-register-buffer-data-sampling.rst | 150 ++++++++++++++++++
 2 files changed, 152 insertions(+)
 create mode 100644 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst

Documentation/admin-guide/hw-vuln/index.rst +2 -0

index 0795e3c2643f..99d5b3244ef9 100644
@@ -14,3 +14,5 @@ are configurable at compile, boot or run time.
    mds
    tsx_async_abort
    multihit.rst
+   special-register-buffer-data-sampling.rst
+

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +2 -0

new file mode 100644
index 000000000000..1fae5f455eb8
@@ -0,0 +1,150 @@
+.. SPDX-License-Identifier: GPL-2.0
+

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst line 8

Quoted 6 lines

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +6 -0

+SRBDS - Special Register Buffer Data Sampling
+=============================================
+
+SRBDS is a hardware vulnerability that allows MDS :doc:`mds` techniques to
+infer values returned from special register accesses.  Special register
+accesses are accesses to off core registers.  According to Intels evaluation,

Intel's

Quoted 48 lines

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +47 -0

+the special register reads that have a security expectation of privacy are:
+RDRAND, RDSEED and SGX EGETKEY.
+
+When RDRAND RDSEED and EGETKEY instructions are used the data is moved to the
+core through the special register mechanism that is susceptible to MDS attacks.
+
+Affected processors
+--------------------
+Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED and
+are vulnerable to MFBDS (Micro architectural Fill Buffer Data Sampling) variant
+of MDS (Micro architectural Data Sampling) or to the TAA (TSX Asynchronous
+Abort) when TSX is enabled,
+
+  =============  ============  ==========================
+  common name    Family_Model  Stepping
+  =============  ============  ==========================
+  Ivybridge      06_3AH        All
+
+  Haswell        06_3CH        All
+  Haswell_L      06_45H        All
+  Haswell_G      06_46H        All
+
+  Broadwell_G    06_47H        All
+  Broadwell      06_3DH        All
+
+  Skylake_L      06_4EH        All
+  Skylake        06_5EH        All
+
+  Kabylake_L     06_8EH        <=A
+  Kabylake_L     06_8EH        0xB only if TSX is enabled
+  Kabylake_L     06_8EH        0xC only if TSX is enabled
+
+  Kabylake       06_9EH        <=B
+  Kabylake       06_9EH        0xC only if TSX is enabled
+  Kabylake       06_9EH        0xD only if TSX is enabled
+  =============  ============  ==========================
+
+Related CVEs
+------------
+
+The following CVE entry is related to this SRBDS issue:
+
+    ==============  =====  =====================================
+    CVE-2020-0543   SRBDS  Speical Register Buffer Data Sampling
+    ==============  =====  =====================================
+
+Attack scenarios

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst line 61

Quoted 6 lines

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +6 -0

+----------------
+An unprivileged user can extract returned values from RDRAND and RDSEED
+executed on another core or sibling thread using MDS techniques.
+
+
+Mitigtion mechanism

Mitigation

Quoted 55 lines

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +54 -0

+-------------------
+Intel will release microcode updates that modify the RDRAND, RDSEED, and
+EGETKEY instructions to overwrite secret special register data in the shared
+staging buffer before the secret data can be accessed by another logical
+processor.
+
+During execution of the RDRAND, RDSEED, or EGETKEY instruction, off-core
+accesses from other logical processors will be delayed until the special
+register read is complete and the secret data in the shared staging buffer is
+overwritten.
+
+This has three effects on performance:
+
+#. RDRAND, RDSEED, or EGETKEY instruction have higher latency.
+
+#. Executing RDRAND at the same time on multiple logical processors will be
+   serialized, resulting in an overall reduction in the maximum RDRAND
+   bandwidth.
+
+#. 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.
+
+Because of the performance impact of the mitigation, the microcode updates also
+provide an opt-out mechanism (RNGDS_MITG_DIS) to disable the mitigation for
+RDRAND and RDSEED instructions executed outside of Intel Software Guard
+Extensions (Intel SGX) enclaves. On logical processors that disable the
+mitigation using this opt-out mechanism, RDRAND and RDSEED do not take longer
+to execute and do not impact performance of sibling logical processors memory
+accesses. The opt-out mechanism does not affect Intel SGX enclaves (including
+execution of RDRAND or RDSEED inside of an enclave, as well as EGETKEY
+execution).
+
+IA32_MCU_OPT_CTRL MSR Definition
+--------------------------------
+Along with the mitigation for this issue, Intel added a new thread-scope
+IA32_MCU_OPT_CTRL MSR, (address 0x123). The presence of this MSR and
+RNGDS_MITG_DIS (bit 0) is enumerated by CPUID.(EAX=07H,ECX=0).EDX[SRBDS_CTRL =
+9]==1. This MSR is introduced through the microcode update.
+
+Setting IA32_MCU_OPT_CTRL[0] (RNGDS_MITG_DIS) to 1 for a logical processor
+disables the mitigation for RDRAND and RDSEED executed outside of an Intel SGX
+enclave on that logical processor. Opting out of the mitigation for a
+particular logical processor does not affect the RDRAND and RDSEED mitigations
+for other logical processors.
+
+Note that inside of an Intel SGX enclave, the mitigation is applied regardless
+of the value of RNGDS_MITG_DS.
+
+Mitigation control on the kernel command line
+---------------------------------------------
+The kernel command line allows control over the SRBDS mitigation at boot time
+with the option "srbds=".  The option for this is:
+

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst line 121

Quoted 6 lines

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +6 -0

+  ============= =============================================================
+  off           This option disables SRBS mitigation for RDRAND and RDSEED on
+                affected platforms.
+  ============= =============================================================
+
+SRBS System Information

SRBDS

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst line 125

Quoted 5 lines

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +4 -0

+-----------------------
+The Linux kernel provides vulnerability status information through sysfs.  For
+SRBDS this can be accessed by the following sysfs file:
+/sys/devices/system/cpu/vulnerabilities/special_register_data_sampling

should be the full name, or "srbds" as I said in my review for patch 2

Quoted 18 lines

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +18 -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                      Processor is vulnerable and mitigation is in
+                                effect.
+ Not affected (TSX disabled)    Processor is only vulnerable when TSX is
+                                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.
+ ============================== =============================================
+

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst line 149

Quoted 6 lines

Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst new file +6 -0

+SRBDS Default mitigation
+------------------------
+This new microcode serializes processor access during execution of RDRAND,
+RDSEED ensures that the shared buffer is overwritten before it is released for
+reuse use the "srbds=off" kernel command line to disable the mitigation for
+RDRAND and RDSEED.

Run-on sentence...

Signature · 2 lines

-- 
Josh

Quoted 11 lines · speck for Josh Poimboeuf

Review

Quoted 8 lines

(quoted diff) +8 -0

+static void __init srbds_select_mitigation(void)
+{
+	u64 ia32_cap;
+
+	if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
+		srbds_mitigation = SRBDS_HYPERVISOR;
+		return;
+	}

It's confusing that this comes before the X86_BUG_SRBDS check. Is that on purpose?

VM vendors on keybase wanted it so.

Quoted 20 lines

Quoted 8 lines

(quoted diff) +4 -0

+
+			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

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 407

Quoted 9 lines

(quoted diff) +6 -0

@@ -397,6 +399,103 @@ 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 __ro_after_init = SRBDS_MITIGATION_FULL;
+static const char * const srbds_strings[] = {
+	[SRBDS_NOT_AFFECTED]		= "Not affected",

I don't think the SRBDS_NOT_AFFECTED enum is needed.

Quoted 4 lines

The "Not affected" string is already printed by cpu_show_common().

And srbds_configure_mitigation() can just check for boot_cpu_has_bug(X86_BUG_SRBDS) instead of this enum value.

True. I prefer having the complete state machine represented by the enumeration but, if you feel strongly I'll try to remove it.

Quoted 4 lines

Quoted 4 lines

(quoted diff) +4 -0

+	[SRBDS_MITIGATION_OFF]		= "Vulnerable",
+	[SRBDS_MITIGATION_UCODE_NEEDED]	= "Vulnerable: no microcode",
+	[SRBDS_MITIGATION_FULL]		= "Mitigated",
+	[SRBDS_NOT_AFFECTED_TSX_OFF]	= "Not affected (TSX disabled)",

Quoted 8 lines

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 417

Quoted 6 lines

(quoted diff) +6 -0

+	[SRBDS_HYPERVISOR]		= "Unknown",
+};
+
+static bool srbds_off;
+
+void srbds_configure_mitigation(void)

To me, "configure" sounds like it could be a software thing.

We are configuring the meditation by honoring the kernel command line in this function.

Quoted 1 line

Quoted 2 lines

How about update_srbds_msr(), which is also more consistent with some of the other naming in the file.

If you like but, I was mimicking the TAA implementation when choosing the name of this function.

Quoted 11 lines

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 425

Quoted 8 lines

(quoted diff) +8 -0

+static void __init srbds_select_mitigation(void)
+{
+	u64 ia32_cap;
+
+	if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
+		srbds_mitigation = SRBDS_HYPERVISOR;
+		return;
+	}

It's confusing that this comes before the X86_BUG_SRBDS check. Is that on purpose?

VM vendors on keybase wanted it so.

Quoted 5 lines

If so, I presume it doesn't have the intended effect, because if booting in a guest on a non-vulnerable CPU, srbds_mitigation will get set to SRBDS_HYPERVISOR, but the shown state will still be "Not affected" because of how cpu_show_common() checks for the bug at the beginning.

The intended effect is to report "Unknown" for the vulnerability status of SRBDS for all guest VM's running this code and to never touch the MSR controlling the mitigation.

I think this is what happens. I'll double check and confirm with testing.

Quoted 25 lines

Quoted 12 lines

(quoted diff) +12 -0

+
+	if (!boot_cpu_has_bug(X86_BUG_SRBDS)) {
+		srbds_mitigation = SRBDS_NOT_AFFECTED;
+		return;
+	}
+
+	if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL)) {
+		srbds_mitigation = SRBDS_MITIGATION_UCODE_NEEDED;
+		return;
+	}
+
+	if (boot_cpu_has_bug(X86_BUG_SRBDS)) {

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 447

Quoted 10 lines

(quoted diff) +10 -0

+		srbds_mitigation = SRBDS_MITIGATION_FULL;
+		/*
+		 * 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) {
+			if (!boot_cpu_has(X86_FEATURE_RTM))
+				srbds_mitigation = SRBDS_NOT_AFFECTED_TSX_OFF;
+		}

I wonder if this would be equivalent?

Quoted 3 lines

		if (!boot_cpu_has_bug(X86_BUG_MDS) && boot_cpu_has(X86_BUG_TAA) &&
		    !boot_cpu_has(X86_FEATURE_RTM))
		    	srbds_mitigation = SRBDS_NOT_AFFECTED_TSX_OFF;

I have no clue if its equivalent but, I find your version much harder to parse and my version matches more closely to what the white paper states.

Quoted 4 lines

Quoted 4 lines

(quoted diff) +4 -0

+	}
+
+	if (cpu_mitigations_off() || srbds_off) {
+		if (srbds_mitigation != SRBDS_NOT_AFFECTED_TSX_OFF)

Quoted 8 lines

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 456

Quoted 5 lines

(quoted diff) +5 -0

+			srbds_mitigation = SRBDS_MITIGATION_OFF;
+	}
+
+	srbds_configure_mitigation();
+}

The other mitigations do a printk with the mitigation status here. Should we not do the same here?

Perhaps but, I was attempting to limit the extra chatter in the kernel logs. If you feel it adds value to the code I'll put it in. FWIW I think the chatter from the other places should be removed.

Quoted 10 lines

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 458

Quoted 2 lines

(quoted diff) +2 -0

+ssize_t cpu_show_special_register_data_sampling(struct device *dev, struct device_attribute *attr, char *buf)
+{

This function name can be renamed to match whatever the filename turns out to be:

cpu_show_srbds()

or

Quoted 1 line

cpu_show_special_register_data_buffer_sampling()

I got some early review feedback to not use the shorter name "srbds" for the sysfs inodes so I was trying to avoid the full spelled out the full names.

"srbds" and "special_register_data_buffer_sampling" do not imply HWRNG security risk so IMO I'd like to just use srbds. What do others think?

Quoted 23 lines

Quoted 12 lines

(quoted diff) +3 -0

+void srbds_configure_mitigation(void);
+
 #ifdef CONFIG_CPU_SUP_INTEL
+
 enum tsx_ctrl_states {
 	TSX_CTRL_ENABLE,
 	TSX_CTRL_DISABLE,

arch/x86/kernel/cpu/intel.c +0 -0

index be82cd5841c3..1b083a2a415b 100644

arch/x86/kernel/cpu/intel.c static void init_intel(struct cpuinfo_x86 *c) · line 689

Quoted 6 lines

arch/x86/kernel/cpu/intel.c +2 -0

@@ -684,6 +684,8 @@ static void init_intel(struct cpuinfo_x86 *c)
 		tsx_enable();
 	if (tsx_ctrl_state == TSX_CTRL_DISABLE)
 		tsx_disable();
+
+	srbds_configure_mitigation();
 }

I'm not sure this is the right place to call this. On the boot CPU, this gets called *before* the mitigation is selected, and then again from srbds_select_mitigation() itself.

Quoted 3 lines

Maybe it should instead be called from identify_secondary_cpu(), while keeping the existing call from srbds_select_mitigation() so the boot CPU also gets updated.

The SRBDS MSR needs to be poked from each CPU thread if you want to disable the mitigation. Does identify_secondary_cpu get called per HW thread?

I felt it would be nice to keep the call close to other mitigation setup logic, in this case the TAA logic.

What do you think it will be more readable if I move it to identify_secondary_cpu?

Quoted 12 lines · speck for mark gross

Quoted 11 lines · speck for Josh Poimboeuf

Review

Quoted 8 lines

(quoted diff) +8 -0

+static void __init srbds_select_mitigation(void)
+{
+	u64 ia32_cap;
+
+	if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
+		srbds_mitigation = SRBDS_HYPERVISOR;
+		return;
+	}

It's confusing that this comes before the X86_BUG_SRBDS check. Is that on purpose?

Quoted 1 line

VM vendors on keybase wanted it so.

No. They don't want this. It results in all multi-socket servers (which are not affected by SRBDS) saying the mitigation status is unknown.

The preferred order to check is:

1) Am I on the affected list?

2) Am I running under a hypervisor?

Initially Andrew Cooper had asked for the hypervisor check to come first. But he has since relented. Below is a comment to explain why it is practially better to check for prescence on the affected list *before* checking for hypervisor:

/*
* This test relies on the CPUID values of vendor, family, model,
* stepping which might not reflect the real hardware when we are
* running as a guest. But VMM vendors have asked that we do this
* before the X86_FEATURE_HYPERVISOR test since this provides better
* guidance to users in most real situations.
*/

Quoted 25 lines · speck for mark gross

Quoted 24 lines

Quoted 8 lines

(quoted diff) +4 -0

+
+			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

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 407

Quoted 9 lines

(quoted diff) +6 -0

@@ -397,6 +399,103 @@ 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 __ro_after_init = SRBDS_MITIGATION_FULL;
+static const char * const srbds_strings[] = {
+	[SRBDS_NOT_AFFECTED]		= "Not affected",

I don't think the SRBDS_NOT_AFFECTED enum is needed.

The "Not affected" string is already printed by cpu_show_common().

And srbds_configure_mitigation() can just check for boot_cpu_has_bug(X86_BUG_SRBDS) instead of this enum value.

Quoted 2 lines

True. I prefer having the complete state machine represented by the enumeration but, if you feel strongly I'll try to remove it.

If the state isn't actually used by the sysfs printing code then it just serves to add confusion for a reader of the code.

And notice none of the other mitigations have this. It's a subtle inconsistency, which is a recipe for future bugs.

Quoted 16 lines

Quoted 4 lines

Quoted 4 lines

(quoted diff) +4 -0

+	[SRBDS_MITIGATION_OFF]		= "Vulnerable",
+	[SRBDS_MITIGATION_UCODE_NEEDED]	= "Vulnerable: no microcode",
+	[SRBDS_MITIGATION_FULL]		= "Mitigated",
+	[SRBDS_NOT_AFFECTED_TSX_OFF]	= "Not affected (TSX disabled)",

Quoted 8 lines

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 417

Quoted 6 lines

(quoted diff) +6 -0

+	[SRBDS_HYPERVISOR]		= "Unknown",
+};
+
+static bool srbds_off;
+
+void srbds_configure_mitigation(void)

To me, "configure" sounds like it could be a software thing.

We are configuring the meditation by honoring the kernel command line in this function.

Quoted 1 line

Quoted 5 lines

Quoted 2 lines

How about update_srbds_msr(), which is also more consistent with some of the other naming in the file.

If you like but, I was mimicking the TAA implementation when choosing the name of this function.

Hm, which TAA function name were you mimicking?

Quoted 24 lines

Quoted 12 lines

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 425

Quoted 9 lines

(quoted diff) +8 -0

+static void __init srbds_select_mitigation(void)
+{
+	u64 ia32_cap;
+
+	if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
+		srbds_mitigation = SRBDS_HYPERVISOR;
+		return;
+	}

It's confusing that this comes before the X86_BUG_SRBDS check. Is that on purpose?

VM vendors on keybase wanted it so.

Quoted 5 lines

If so, I presume it doesn't have the intended effect, because if booting in a guest on a non-vulnerable CPU, srbds_mitigation will get set to SRBDS_HYPERVISOR, but the shown state will still be "Not affected" because of how cpu_show_common() checks for the bug at the beginning.

The intended effect is to report "Unknown" for the vulnerability status of SRBDS for all guest VM's running this code and to never touch the MSR controlling the mitigation.

Quoted 1 line

I think this is what happens. I'll double check and confirm with testing.

Maybe I'm blind, but given how cpu_show_common() works, I don't see how that could possibly happen when boot_cpu_has_bug(X86_BUG_SRBDS) is false. If I'm wrong please enlighten me.

Quoted 25 lines

Quoted 25 lines

Quoted 12 lines

(quoted diff) +12 -0

+
+	if (!boot_cpu_has_bug(X86_BUG_SRBDS)) {
+		srbds_mitigation = SRBDS_NOT_AFFECTED;
+		return;
+	}
+
+	if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL)) {
+		srbds_mitigation = SRBDS_MITIGATION_UCODE_NEEDED;
+		return;
+	}
+
+	if (boot_cpu_has_bug(X86_BUG_SRBDS)) {

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 447

Quoted 10 lines

(quoted diff) +10 -0

+		srbds_mitigation = SRBDS_MITIGATION_FULL;
+		/*
+		 * 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) {
+			if (!boot_cpu_has(X86_FEATURE_RTM))
+				srbds_mitigation = SRBDS_NOT_AFFECTED_TSX_OFF;
+		}

I wonder if this would be equivalent?

Quoted 5 lines

Quoted 3 lines

		if (!boot_cpu_has_bug(X86_BUG_MDS) && boot_cpu_has(X86_BUG_TAA) &&
		    !boot_cpu_has(X86_FEATURE_RTM))
		    	srbds_mitigation = SRBDS_NOT_AFFECTED_TSX_OFF;

I have no clue if its equivalent but, I find your version much harder to parse and my version matches more closely to what the white paper states.

Ok.

Quoted 12 lines

Quoted 12 lines

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 456

Quoted 9 lines

(quoted diff) +9 -0

+	}
+
+	if (cpu_mitigations_off() || srbds_off) {
+		if (srbds_mitigation != SRBDS_NOT_AFFECTED_TSX_OFF)
+			srbds_mitigation = SRBDS_MITIGATION_OFF;
+	}
+
+	srbds_configure_mitigation();
+}

The other mitigations do a printk with the mitigation status here. Should we not do the same here?

Quoted 3 lines

Perhaps but, I was attempting to limit the extra chatter in the kernel logs. If you feel it adds value to the code I'll put it in. FWIW I think the chatter from the other places should be removed.

It should at least be consistent with the others.

Quoted 12 lines

Quoted 11 lines

Review static int __init tsx_async_abort_parse_cmdline(char *str) · line 458

Quoted 2 lines

(quoted diff) +2 -0

+ssize_t cpu_show_special_register_data_sampling(struct device *dev, struct device_attribute *attr, char *buf)
+{

This function name can be renamed to match whatever the filename turns out to be:

cpu_show_srbds()

or

cpu_show_special_register_data_buffer_sampling()

Quoted 5 lines

I got some early review feedback to not use the shorter name "srbds" for the sysfs inodes so I was trying to avoid the full spelled out the full names.

"srbds" and "special_register_data_buffer_sampling" do not imply HWRNG security risk so IMO I'd like to just use srbds. What do others think?

+1 for "srbds" for both file name and function name.

Quoted 23 lines

Quoted 23 lines

Quoted 12 lines

(quoted diff) +3 -0

+void srbds_configure_mitigation(void);
+
 #ifdef CONFIG_CPU_SUP_INTEL
+
 enum tsx_ctrl_states {
 	TSX_CTRL_ENABLE,
 	TSX_CTRL_DISABLE,

arch/x86/kernel/cpu/intel.c +0 -0

index be82cd5841c3..1b083a2a415b 100644

arch/x86/kernel/cpu/intel.c static void init_intel(struct cpuinfo_x86 *c) · line 689

Quoted 6 lines

arch/x86/kernel/cpu/intel.c +2 -0

@@ -684,6 +684,8 @@ static void init_intel(struct cpuinfo_x86 *c)
 		tsx_enable();
 	if (tsx_ctrl_state == TSX_CTRL_DISABLE)
 		tsx_disable();
+
+	srbds_configure_mitigation();
 }

I'm not sure this is the right place to call this. On the boot CPU, this gets called *before* the mitigation is selected, and then again from srbds_select_mitigation() itself.

Quoted 5 lines

Quoted 3 lines

Maybe it should instead be called from identify_secondary_cpu(), while keeping the existing call from srbds_select_mitigation() so the boot CPU also gets updated.

The SRBDS MSR needs to be poked from each CPU thread if you want to disable the mitigation. Does identify_secondary_cpu get called per HW thread?

identify_secondary_cpu() gets called for every HW thread, other than the boot one.

The boot one already does it in srbds_select_mitigation().

Quoted 2 lines

I felt it would be nice to keep the call close to other mitigation setup logic, in this case the TAA logic.

That's not the TAA logic, but rather the TSX logic (though yes I realize they're related). And anyway SRBDS and TSX have different requirements.

Quoted 2 lines

What do you think it will be more readable if I move it to identify_secondary_cpu?

As I said - it gets called *twice* on the boot CPU. The first time is before srbds_mitigation has even been configured. That's confusing.

Signature · 1 line

Josh