* [MODERATED] [PATCH 3/4] v6 more sampling fun 3
2020-04-09 18:36 [MODERATED] [PATCH 0/4] v6 more sampling fun 0 mark gross
@ 2020-01-16 22:16 ` mark gross
2020-01-30 19:12 ` [MODERATED] [PATCH 4/4] v6 more sampling fun 4 mark gross
` (4 subsequent siblings)
5 siblings, 0 replies; 9+ messages in thread
From: mark gross @ 2020-01-16 22:16 UTC (permalink / raw)
To: speck
From: mark gross <mgross@linux.intel.com>
Subject: [PATCH 3/4] 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 <mgross@linux.intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Tested-by: Neelima Krishnan <neelima.krishnan@intel.com>
---
.../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 | 116 ++++++++++++++++++
arch/x86/kernel/cpu/common.c | 43 +++++++
arch/x86/kernel/cpu/cpu.h | 2 +
drivers/base/cpu.c | 8 ++
8 files changed, 196 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 2e0e3b45d02a..b39531a3c5bc 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -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
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 86aae1fa099a..05817d4f2786 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4753,6 +4753,26 @@
the kernel will oops in either "warn" or "fatal"
mode.
+ srbds= [X86,INTEL]
+ Control mitigation for 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
diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
index db189945e9b0..02dabc9e77b0 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -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 */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 12c9684d59ba..3efde600a674 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -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
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index ed54b3b21c39..addef92109fe 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -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,107 @@ 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_NOT_AFFECTED_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] = "Mitigated: Microcode",
+ [SRBDS_MITIGATION_NOT_AFFECTED_TSX_OFF] = "Not affected (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_NOT_AFFECTED_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_NOT_AFFECTED_TSX_OFF;
+ goto out;
+ }
+
+ if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) {
+ srbds_mitigation = SRBDS_MITIGATION_HYPERVISOR;
+ goto out;
+ }
+
+ if (!boot_cpu_has(X86_FEATURE_SRBDS_CTRL)) {
+ srbds_mitigation = SRBDS_MITIGATION_UCODE_NEEDED;
+ goto out;
+ }
+
+ if (cpu_mitigations_off() || srbds_off) {
+ if (srbds_mitigation != SRBDS_MITIGATION_NOT_AFFECTED_TSX_OFF)
+ srbds_mitigation = SRBDS_MITIGATION_OFF;
+ }
+out:
+ 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 +1631,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 +1680,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 +1729,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
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 2bea1cc8dcb4..c070c1f1f4b8 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1075,6 +1075,27 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = {
{}
};
+#define VULNBL_INTEL_STEPPING(model, steppings, issues) \
+ X86_MATCH_VENDOR_FAM_MODEL_STEPPING_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_STEPPING(IVYBRIDGE, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPING(HASWELL, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPING(HASWELL_L, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPING(HASWELL_G, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPING(BROADWELL_G, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPING(BROADWELL, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPING(SKYLAKE_L, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPING(SKYLAKE, X86_STEPPING_ANY, SRBDS),
+ VULNBL_INTEL_STEPPING(KABYLAKE_L, GENMASK(0xC, 0), SRBDS), /*06_8E steppings <=C*/
+ VULNBL_INTEL_STEPPING(KABYLAKE, GENMASK(0xD, 0), SRBDS), /*06_9E steppings <=D*/
+ {}
+};
+
static bool __init cpu_matches(unsigned long which, const struct x86_cpu_id *table)
{
const struct x86_cpu_id *m = x86_match_cpu(table);
@@ -1142,6 +1163,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);
+ if (cpu_matches(SRBDS, cpu_vuln_blacklist)) {
+ /*
+ * 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))
+ goto srbds_not_affected;
+ /*
+ * Parts that have TSX fused off and are not affected by MDS
+ * are not affected by SRBDS. TSX_CTRL is only enumerated on
+ * parts where TSX fused on.
+ */
+ if ((ia32_cap & ARCH_CAP_MDS_NO) &&
+ !(ia32_cap & ARCH_CAP_TSX_CTRL_MSR))
+ goto srbds_not_affected;
+
+ setup_force_cpu_bug(X86_BUG_SRBDS);
+ }
+srbds_not_affected:
+
if (cpu_matches(NO_MELTDOWN, cpu_vuln_whitelist))
return;
@@ -1594,6 +1636,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)
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index 37fdefd14f28..f3e2fc44dba0 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -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,
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 9a1c00fbbaef..d2136ab9b14a 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -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
};
--
2.17.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [MODERATED] [PATCH 4/4] v6 more sampling fun 4
2020-04-09 18:36 [MODERATED] [PATCH 0/4] v6 more sampling fun 0 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 3/4] v6 more sampling fun 3 mark gross
@ 2020-01-30 19:12 ` mark gross
2020-03-17 0:56 ` [MODERATED] [PATCH 2/4] v6 more sampling fun 2 mark gross
` (3 subsequent siblings)
5 siblings, 0 replies; 9+ messages in thread
From: mark gross @ 2020-01-30 19:12 UTC (permalink / raw)
To: speck
From: mark gross <mgross@linux.intel.com>
Subject: [PATCH 4/4] x86/speculation: SRBDS vulnerability and mitigation
documentation
Add documentation for the SRBDS vulnerability and its mitigation.
Reviewed-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Mark Gross <mgross@linux.intel.com>
---
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../special-register-buffer-data-sampling.rst | 148 ++++++++++++++++++
2 files changed, 149 insertions(+)
create mode 100644 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst
index 0795e3c2643f..ca4dbdd9016d 100644
--- a/Documentation/admin-guide/hw-vuln/index.rst
+++ b/Documentation/admin-guide/hw-vuln/index.rst
@@ -14,3 +14,4 @@ are configurable at compile, boot or run time.
mds
tsx_async_abort
multihit.rst
+ special-register-buffer-data-sampling.rst
diff --git a/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
new file mode 100644
index 000000000000..9967478eaeee
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
@@ -0,0 +1,148 @@
+.. SPDX-License-Identifier: GPL-2.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 Intel's evaluation,
+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 Special Register Buffer Data Sampling
+ ============== ===== =====================================
+
+Attack scenarios
+----------------
+An unprivileged user can extract returned values from RDRAND and RDSEED
+executed on another core or sibling thread using MDS techniques.
+
+
+Mitigation mechanism
+-------------------
+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.
+
+The microcode updates 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:
+
+ ============= =============================================================
+ off This option disables SRBDS mitigation for RDRAND and RDSEED on
+ affected platforms.
+ ============= =============================================================
+
+SRBDS System Information
+-----------------------
+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/srbds
+
+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.
+ ============================== =============================================
+
+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.
--
2.17.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [MODERATED] [PATCH 1/4] v6 more sampling fun 1
2020-04-09 18:36 [MODERATED] [PATCH 0/4] v6 more sampling fun 0 mark gross
` (2 preceding siblings ...)
2020-03-17 0:56 ` [MODERATED] [PATCH 2/4] v6 more sampling fun 2 mark gross
@ 2020-03-17 0:56 ` mark gross
2020-04-09 22:36 ` [PATCH 3/4] v6 more sampling fun 3 Thomas Gleixner
[not found] ` <585879ee414f627d2f5b8b5d63a13e35c9aa0688.158645=?utf-8?q?7409?= .git.mgross@linux.intel.com>
5 siblings, 0 replies; 9+ messages in thread
From: mark gross @ 2020-03-17 0:56 UTC (permalink / raw)
To: speck
From: mark gross <mgross@linux.intel.com>
Subject: [PATCH 1/4] 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.
On X86 there can be at most 16 steppings, add steppings bitmask to
x86_cpu_id and X86_MATCH_VENDOR_FAMILY_MODEL_STEPPING_FEATURE macro and
support for matching against family/model/stepping.
Signed-off-by: Mark Gross <mgross@linux.intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
arch/x86/include/asm/cpu_device_id.h | 26 +++++++++++++++++++++++---
arch/x86/kernel/cpu/match.c | 7 ++++++-
include/linux/mod_devicetable.h | 2 ++
3 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
index cf3d621c6892..d8ecd0d72e04 100644
--- a/arch/x86/include/asm/cpu_device_id.h
+++ b/arch/x86/include/asm/cpu_device_id.h
@@ -21,11 +21,12 @@
#define X86_CENTAUR_FAM6_NANO 0xf
/**
- * X86_MATCH_VENDOR_FAM_MODEL_FEATURE - Base macro for CPU matching
+ * X86_MATCH_VENDOR_FAM_MODEL_STEPPING_FEATURE - Base macro for CPU matching
* @_vendor: The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY
* The name is expanded to X86_VENDOR_@_vendor
* @_family: The family number or X86_FAMILY_ANY
* @_model: The model number, model constant or X86_MODEL_ANY
+ * @_steppings: Bitmask for steppings, stepping constant or X86_STEPPING_ANY
* @_feature: A X86_FEATURE bit or X86_FEATURE_ANY
* @_data: Driver specific data or NULL. The internal storage
* format is unsigned long. The supplied value, pointer
@@ -37,15 +38,34 @@
* into another macro at the usage site for good reasons, then please
* start this local macro with X86_MATCH to allow easy grepping.
*/
-#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(_vendor, _family, _model, \
- _feature, _data) { \
+#define X86_MATCH_VENDOR_FAM_MODEL_STEPPING_FEATURE(_vendor, _family, _model, \
+ _steppings, _feature, _data) { \
.vendor = X86_VENDOR_##_vendor, \
.family = _family, \
.model = _model, \
+ .steppings = _steppings, \
.feature = _feature, \
.driver_data = (unsigned long) _data \
}
+/**
+ * X86_MATCH_VENDOR_FAM_MODEL_FEATURE - Base macro for CPU matching
+ * @_vendor: The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY
+ * The name is expanded to X86_VENDOR_@_vendor
+ * @_family: The family number or X86_FAMILY_ANY
+ * @_model: The model number, model constant or X86_MODEL_ANY
+ * @_feature: A X86_FEATURE bit or X86_FEATURE_ANY
+ * @_data: Driver specific data or NULL. The internal storage
+ * format is unsigned long. The supplied value, pointer
+ * etc. is casted to unsigned long internally.
+ *
+ * The steppings arguments of X86_MATCH_VENDOR_FAM_MODEL_STEPPING_FEATURE() is
+ * set to wildcards.
+ */
+#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, feature, data) \
+ X86_MATCH_VENDOR_FAM_MODEL_STEPPING_FEATURE(vendor, family, model, \
+ X86_STEPPING_ANY, feature, data)
+
/**
* X86_MATCH_VENDOR_FAM_FEATURE - Macro for matching vendor, family and CPU feature
* @vendor: The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY
diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c
index d3482eb43ff3..ad6776081e60 100644
--- a/arch/x86/kernel/cpu/match.c
+++ b/arch/x86/kernel/cpu/match.c
@@ -39,13 +39,18 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match)
const struct x86_cpu_id *m;
struct cpuinfo_x86 *c = &boot_cpu_data;
- for (m = match; m->vendor | m->family | m->model | m->feature; m++) {
+ for (m = match;
+ m->vendor | m->family | m->model | m->steppings | m->feature;
+ m++) {
if (m->vendor != X86_VENDOR_ANY && c->x86_vendor != m->vendor)
continue;
if (m->family != X86_FAMILY_ANY && c->x86 != m->family)
continue;
if (m->model != X86_MODEL_ANY && c->x86_model != m->model)
continue;
+ if (m->steppings != X86_STEPPING_ANY &&
+ !(BIT(c->x86_stepping) & m->steppings))
+ continue;
if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature))
continue;
return m;
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 4c2ddd0941a7..0754b8d71262 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -663,6 +663,7 @@ struct x86_cpu_id {
__u16 vendor;
__u16 family;
__u16 model;
+ __u16 steppings;
__u16 feature; /* bit index */
kernel_ulong_t driver_data;
};
@@ -671,6 +672,7 @@ struct x86_cpu_id {
#define X86_VENDOR_ANY 0xffff
#define X86_FAMILY_ANY 0
#define X86_MODEL_ANY 0
+#define X86_STEPPING_ANY 0
#define X86_FEATURE_ANY 0 /* Same as FPU, you can't test for that */
/*
--
2.17.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [MODERATED] [PATCH 2/4] v6 more sampling fun 2
2020-04-09 18:36 [MODERATED] [PATCH 0/4] v6 more sampling fun 0 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 3/4] v6 more sampling fun 3 mark gross
2020-01-30 19:12 ` [MODERATED] [PATCH 4/4] v6 more sampling fun 4 mark gross
@ 2020-03-17 0:56 ` mark gross
2020-03-17 0:56 ` [MODERATED] [PATCH 1/4] v6 more sampling fun 1 mark gross
` (2 subsequent siblings)
5 siblings, 0 replies; 9+ messages in thread
From: mark gross @ 2020-03-17 0:56 UTC (permalink / raw)
To: speck
From: mark gross <mgross@linux.intel.com>
Subject: [PATCH 2/4] x86/cpu: clean up cpu_matches
To make cpu_matches reusable for alternitive matching tables, make cpu_matches
take a x86_cpu_id table as a parameter.
Signed-off-by: Mark Gross <mgross@linux.intel.com>
---
arch/x86/kernel/cpu/common.c | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index bed0cb83fe24..2bea1cc8dcb4 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -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(unsigned long which, const struct x86_cpu_id *table)
{
- 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(NO_ITLB_MULTIHIT, cpu_vuln_whitelist) &&
+ !(ia32_cap & ARCH_CAP_PSCHANGE_MC_NO))
setup_force_cpu_bug(X86_BUG_ITLB_MULTIHIT);
- if (cpu_matches(NO_SPECULATION))
+ if (cpu_matches(NO_SPECULATION, cpu_vuln_whitelist))
return;
setup_force_cpu_bug(X86_BUG_SPECTRE_V1);
- if (!cpu_matches(NO_SPECTRE_V2))
+ if (!cpu_matches(NO_SPECTRE_V2, cpu_vuln_whitelist))
setup_force_cpu_bug(X86_BUG_SPECTRE_V2);
- if (!cpu_matches(NO_SSB) && !(ia32_cap & ARCH_CAP_SSB_NO) &&
+ if (!cpu_matches(NO_SSB, cpu_vuln_whitelist) &&
+ !(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(NO_MDS, cpu_vuln_whitelist) &&
+ !(ia32_cap & ARCH_CAP_MDS_NO)) {
setup_force_cpu_bug(X86_BUG_MDS);
- if (cpu_matches(MSBDS_ONLY))
+ if (cpu_matches(MSBDS_ONLY, cpu_vuln_whitelist))
setup_force_cpu_bug(X86_BUG_MSBDS_ONLY);
}
- if (!cpu_matches(NO_SWAPGS))
+ if (!cpu_matches(NO_SWAPGS, cpu_vuln_whitelist))
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(NO_MELTDOWN, cpu_vuln_whitelist))
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(NO_L1TF, cpu_vuln_whitelist))
return;
setup_force_cpu_bug(X86_BUG_L1TF);
--
2.17.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [MODERATED] [PATCH 0/4] v6 more sampling fun 0
@ 2020-04-09 18:36 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 3/4] v6 more sampling fun 3 mark gross
` (5 more replies)
0 siblings, 6 replies; 9+ messages in thread
From: mark gross @ 2020-04-09 18:36 UTC (permalink / raw)
To: speck
From: mark gross <mgross@linux.intel.com>
Subject: [PATCH 0/4] v6 more sampling fun
resend because I forgot the --thread option on the format-patch.
sorry for the spam
This version of the Special Register Buffer Data Sampling has been updated to
address feedback gotten. Including:
* is based on linus/master from this AM.
* cleanups and changes driven by review feedback from Josh and Thomas.
* addresses the case of intel fusing TSX off on lower end SKU's
* spits out some refactoring from the main patch to better isolate the SRBDS
specific changes.
Thanks to all who have given me feedback on this.
---
Special Register Buffer Data Sampling is a sampling type of vulnerability that
leaks data across cores sharing the HW-RNG for vulnerable processors.
This leak is fixed by a microcode update and is enabled by default.
This new microcode serializes processor access during execution of RDRAND or
RDSEED. It ensures that the shared buffer is overwritten before it is released
for reuse.
The mitigation impacts the throughput of the RDRAND and RDSEED instructions and
latency of RT processing running on the socket while executing RDRAND or
RDSEED. The micro benchmarks calling RDRAND many times show a slowdown.
This patch set enables kernel command line control of this mitigation and
exports vulnerability and mitigation status.
This patch set includes 3 patches:
* The first patch adds steppings to x86_cpu_id structure and related macros
* The second patch enables the command line control of the mitigation as well
as the sysfs export of vulnerability status.
* The third patch has the Documentation/admin-guide/hw-vuln documentation for
this issue and the control over the mitigation.
mark gross (4):
x86/cpu: Add stepping field to x86_cpu_id structure
x86/cpu: clean up cpu_matches
x86/speculation: Special Register Buffer Data Sampling (SRBDS)
mitigation control.
x86/speculation: SRBDS vulnerability and mitigation documentation
.../ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/admin-guide/hw-vuln/index.rst | 1 +
.../special-register-buffer-data-sampling.rst | 148 ++++++++++++++++++
.../admin-guide/kernel-parameters.txt | 20 +++
arch/x86/include/asm/cpu_device_id.h | 26 ++-
arch/x86/include/asm/cpufeatures.h | 2 +
arch/x86/include/asm/msr-index.h | 4 +
arch/x86/kernel/cpu/bugs.c | 116 ++++++++++++++
arch/x86/kernel/cpu/common.c | 68 ++++++--
arch/x86/kernel/cpu/cpu.h | 2 +
arch/x86/kernel/cpu/match.c | 7 +-
drivers/base/cpu.c | 8 +
include/linux/mod_devicetable.h | 2 +
13 files changed, 390 insertions(+), 15 deletions(-)
create mode 100644 Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
--
2.17.1
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 3/4] v6 more sampling fun 3
2020-04-09 18:36 [MODERATED] [PATCH 0/4] v6 more sampling fun 0 mark gross
` (3 preceding siblings ...)
2020-03-17 0:56 ` [MODERATED] [PATCH 1/4] v6 more sampling fun 1 mark gross
@ 2020-04-09 22:36 ` Thomas Gleixner
2020-04-12 15:29 ` [MODERATED] " mark gross
[not found] ` <585879ee414f627d2f5b8b5d63a13e35c9aa0688.158645=?utf-8?q?7409?= .git.mgross@linux.intel.com>
5 siblings, 1 reply; 9+ messages in thread
From: Thomas Gleixner @ 2020-04-09 22:36 UTC (permalink / raw)
To: speck
Mark,
speck for mark gross <speck@linutronix.de> writes:
> +#define VULNBL_INTEL_STEPPING(model, steppings, issues) \
> + X86_MATCH_VENDOR_FAM_MODEL_STEPPING_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_STEPPING(IVYBRIDGE, X86_STEPPING_ANY, SRBDS),
> + VULNBL_INTEL_STEPPING(HASWELL, X86_STEPPING_ANY, SRBDS),
> + VULNBL_INTEL_STEPPING(HASWELL_L, X86_STEPPING_ANY, SRBDS),
> + VULNBL_INTEL_STEPPING(HASWELL_G, X86_STEPPING_ANY, SRBDS),
> + VULNBL_INTEL_STEPPING(BROADWELL_G, X86_STEPPING_ANY, SRBDS),
> + VULNBL_INTEL_STEPPING(BROADWELL, X86_STEPPING_ANY, SRBDS),
> + VULNBL_INTEL_STEPPING(SKYLAKE_L, X86_STEPPING_ANY, SRBDS),
> + VULNBL_INTEL_STEPPING(SKYLAKE, X86_STEPPING_ANY, SRBDS),
> + VULNBL_INTEL_STEPPING(KABYLAKE_L, GENMASK(0xC, 0), SRBDS), /*06_8E steppings <=C*/
> + VULNBL_INTEL_STEPPING(KABYLAKE, GENMASK(0xD, 0), SRBDS), /*06_9E steppings <=D*/
Please don't use these horrible tail comments. Also the 06_NN part is of
that comment is not helpful either. Please make stuff self explaining,
i.e.
#define X86_STEPPINGS(mins, maxs) GENMASK(maxs, mins)
and use that in the blacklist:
VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0, 0xC), SRBDS),
VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0, 0xD), SRBDS),
which is pretty obvious, right?
> static bool __init cpu_matches(unsigned long which, const struct x86_cpu_id *table)
> {
> const struct x86_cpu_id *m = x86_match_cpu(table);
> @@ -1142,6 +1163,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);
>
> + if (cpu_matches(SRBDS, cpu_vuln_blacklist)) {
> + /*
> + * 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))
> + goto srbds_not_affected;
> + /*
> + * Parts that have TSX fused off and are not affected by MDS
> + * are not affected by SRBDS. TSX_CTRL is only enumerated on
> + * parts where TSX fused on.
> + */
> + if ((ia32_cap & ARCH_CAP_MDS_NO) &&
> + !(ia32_cap & ARCH_CAP_TSX_CTRL_MSR))
> + goto srbds_not_affected;
This is confusing vs. the documentation patch:
>+ 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
IOW, this is only true for particular steppings of Kabylake[_L]
It might well be the case that exactly these steppings have MDS_NO and
might have TSX fused off, but can we pretty please make this very
explicit?
VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0x0, 0xA), SRBDS),
VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0xB, 0xC), SRBDS_IF_TSX),
VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0x0, 0xB), SRBDS),
VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0xC, 0xD), SRBDS_IF_TSX),
and make the check for SRBDS_IF_TSX & TSX enabled in the code? You
surely figure out how to define SRBDS_IF_TSX so the SRBDS match works
for both :)
Thanks,
tglx
^ permalink raw reply [flat|nested] 9+ messages in thread
* [MODERATED] Re: [PATCH 4/4] v6 more sampling fun 4
[not found] ` <585879ee414f627d2f5b8b5d63a13e35c9aa0688.158645=?utf-8?q?7409?= .git.mgross@linux.intel.com>
@ 2020-04-11 19:46 ` Ben Hutchings
2020-04-12 15:33 ` mark gross
0 siblings, 1 reply; 9+ messages in thread
From: Ben Hutchings @ 2020-04-11 19:46 UTC (permalink / raw)
To: speck
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
On Thu, 2020-01-30 at 11:12 -0800, speck for mark gross wrote:
[...]
> +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.
> + ============================== =============================================
[...]
The values in this table haven't been updated along with the code.
Ben.
--
Ben Hutchings
Knowledge is power. France is bacon.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* [MODERATED] Re: [PATCH 3/4] v6 more sampling fun 3
2020-04-09 22:36 ` [PATCH 3/4] v6 more sampling fun 3 Thomas Gleixner
@ 2020-04-12 15:29 ` mark gross
0 siblings, 0 replies; 9+ messages in thread
From: mark gross @ 2020-04-12 15:29 UTC (permalink / raw)
To: speck
On Fri, Apr 10, 2020 at 12:36:09AM +0200, speck for Thomas Gleixner wrote:
> Mark,
>
> speck for mark gross <speck@linutronix.de> writes:
> > +#define VULNBL_INTEL_STEPPING(model, steppings, issues) \
> > + X86_MATCH_VENDOR_FAM_MODEL_STEPPING_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_STEPPING(IVYBRIDGE, X86_STEPPING_ANY, SRBDS),
> > + VULNBL_INTEL_STEPPING(HASWELL, X86_STEPPING_ANY, SRBDS),
> > + VULNBL_INTEL_STEPPING(HASWELL_L, X86_STEPPING_ANY, SRBDS),
> > + VULNBL_INTEL_STEPPING(HASWELL_G, X86_STEPPING_ANY, SRBDS),
> > + VULNBL_INTEL_STEPPING(BROADWELL_G, X86_STEPPING_ANY, SRBDS),
> > + VULNBL_INTEL_STEPPING(BROADWELL, X86_STEPPING_ANY, SRBDS),
> > + VULNBL_INTEL_STEPPING(SKYLAKE_L, X86_STEPPING_ANY, SRBDS),
> > + VULNBL_INTEL_STEPPING(SKYLAKE, X86_STEPPING_ANY, SRBDS),
> > + VULNBL_INTEL_STEPPING(KABYLAKE_L, GENMASK(0xC, 0), SRBDS), /*06_8E steppings <=C*/
> > + VULNBL_INTEL_STEPPING(KABYLAKE, GENMASK(0xD, 0), SRBDS), /*06_9E steppings <=D*/
>
> Please don't use these horrible tail comments. Also the 06_NN part is of
> that comment is not helpful either. Please make stuff self explaining,
> i.e.
tail comments gone.
> #define X86_STEPPINGS(mins, maxs) GENMASK(maxs, mins)
Adding this to the patch where I introduced steppings to x86_cpu_id.
>
> and use that in the blacklist:
>
> VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0, 0xC), SRBDS),
> VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0, 0xD), SRBDS),
>
> which is pretty obvious, right?
right!
> > static bool __init cpu_matches(unsigned long which, const struct x86_cpu_id *table)
> > {
> > const struct x86_cpu_id *m = x86_match_cpu(table);
> > @@ -1142,6 +1163,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);
> >
> > + if (cpu_matches(SRBDS, cpu_vuln_blacklist)) {
> > + /*
> > + * 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))
> > + goto srbds_not_affected;
> > + /*
> > + * Parts that have TSX fused off and are not affected by MDS
> > + * are not affected by SRBDS. TSX_CTRL is only enumerated on
> > + * parts where TSX fused on.
> > + */
> > + if ((ia32_cap & ARCH_CAP_MDS_NO) &&
> > + !(ia32_cap & ARCH_CAP_TSX_CTRL_MSR))
> > + goto srbds_not_affected;
>
> This is confusing vs. the documentation patch:
I'll try to make it better.
attempt made. I will post it Monday.
> >+ 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
>
> IOW, this is only true for particular steppings of Kabylake[_L]
>
> It might well be the case that exactly these steppings have MDS_NO and
> might have TSX fused off, but can we pretty please make this very
> explicit?
I thought that might be the case to but, I was told that the choice to fuse
stuff off is made by marketing per bin splits. i.e. Kabylake i3's or Celerons
will get the features fused off not all kabylakes or specific steppings.
> VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0x0, 0xA), SRBDS),
> VULNBL_INTEL_STEPPING(KABYLAKE_L, X86_STEPPINGS(0xB, 0xC), SRBDS_IF_TSX),
> VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0x0, 0xB), SRBDS),
> VULNBL_INTEL_STEPPING(KABYLAKE, X86_STEPPINGS(0xC, 0xD), SRBDS_IF_TSX),
>
> and make the check for SRBDS_IF_TSX & TSX enabled in the code? You
> surely figure out how to define SRBDS_IF_TSX so the SRBDS match works
> for both :)
In fact that was somewhat how I hand the code initialy implemented treating the
"onyl if tsx" case as a separate match bit.
Added SRBDS_IF_TSX to make the code more self documenting and more closely
match documentation.
done.
>
> Thanks,
>
> tglx
Thank you!
--mark
^ permalink raw reply [flat|nested] 9+ messages in thread
* [MODERATED] Re: [PATCH 4/4] v6 more sampling fun 4
2020-04-11 19:46 ` [MODERATED] Re: [PATCH 4/4] v6 more sampling fun 4 Ben Hutchings
@ 2020-04-12 15:33 ` mark gross
0 siblings, 0 replies; 9+ messages in thread
From: mark gross @ 2020-04-12 15:33 UTC (permalink / raw)
To: speck
On Sat, Apr 11, 2020 at 08:46:05PM +0100, speck for Ben Hutchings wrote:
> On Thu, 2020-01-30 at 11:12 -0800, speck for mark gross wrote:
> [...]
> > +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.
> > + ============================== =============================================
> [...]
>
> The values in this table haven't been updated along with the code.
updated Mitigated line to match exactly with code.
--mark
> Ben.
>
> --
> Ben Hutchings
> Knowledge is power. France is bacon.
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-04-12 15:33 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-09 18:36 [MODERATED] [PATCH 0/4] v6 more sampling fun 0 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 3/4] v6 more sampling fun 3 mark gross
2020-01-30 19:12 ` [MODERATED] [PATCH 4/4] v6 more sampling fun 4 mark gross
2020-03-17 0:56 ` [MODERATED] [PATCH 2/4] v6 more sampling fun 2 mark gross
2020-03-17 0:56 ` [MODERATED] [PATCH 1/4] v6 more sampling fun 1 mark gross
2020-04-09 22:36 ` [PATCH 3/4] v6 more sampling fun 3 Thomas Gleixner
2020-04-12 15:29 ` [MODERATED] " mark gross
[not found] ` <585879ee414f627d2f5b8b5d63a13e35c9aa0688.158645=?utf-8?q?7409?= .git.mgross@linux.intel.com>
2020-04-11 19:46 ` [MODERATED] Re: [PATCH 4/4] v6 more sampling fun 4 Ben Hutchings
2020-04-12 15:33 ` mark gross
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).