From: mark gross <mgross@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] [PATCH 2/2] v3 more sampling fun 2
Date: Thu, 30 Jan 2020 11:12:02 -0800 [thread overview]
Message-ID: <=?utf-8?q?=3Cb3ce08567ed48062f9d1e0f166cc35afce7316af=2E158394?= =?utf-8?q?1169=2Egit=2Emgross=40linux=2Eintel=2Ecom=3E?=> (raw)
In-Reply-To: <cover.1583941169.git.mgross@linux.intel.com>
From: mark gross <mgross@linux.intel.com>
Subject: [PATCH 2/2] x86/speculation: SRBDS vulnerability and mitigation
documentation
Adds 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 | 2 +
.../special-register-buffer-data-sampling.rst | 145 ++++++++++++++++++
2 files changed, 147 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..99d5b3244ef9 100644
--- a/Documentation/admin-guide/hw-vuln/index.rst
+++ b/Documentation/admin-guide/hw-vuln/index.rst
@@ -14,3 +14,5 @@ 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..5acc7748f8e9
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst
@@ -0,0 +1,145 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+SRBDS - Special Register Buffer Data Sampling
+======================================
+
+SRBDS is a hardware vulnerability that allows MDS techniques to infer values
+returned from special register accesses. Special register accesses are
+accesses to off core registers. According to Intels evaluation, the special
+register reads that have a security expectation of privacy are:
+RDRAND, RDSEED and SGX EGETKEY.
+
+When RDRAND and RDSEED instructions are used the data is moved to the core
+through the special register mechanism.
+
+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 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
+ ============== ===== ===================================================
+
+Attack scenarios
+---------------
+An unprivileged user can extract returned values from RDRAND and RDSEED
+executed on another core or sibling thread using MDS techniques.
+
+
+Mitigtion 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:
+1 RDRAND, RDSEED, or EGETKEY instruction have higher latency.
+2 Executing RDRAND at the same time on multiple logical processors will be
+ serialized, resulting in an overall reduction in the maximum RDRAND bandwidth.
+3 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 for control over the SRBDS mitigation at boot
+time with the option "srbds=". The option for this is:
+
+ ============= ============================================================
+ off This option disables SRBS mitigation for RDRAND and RDSEED on
+ affected platforms.
+ ============= ============================================================
+
+SRBS 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/special_register_data_sampling
+
+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.
+ ============================== ===========================================
+
+Default mitigations
+-------------------
+This new microcode serializes processor access during execution of RDRAND,
+RDSEED ensures that the shared buffer is overwritten before it is released for
+reuse.
+
--
2.17.1
next prev parent reply other threads:[~2020-03-11 16:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-11 15:39 [MODERATED] [PATCH 0/2] v3 more sampling fun 0 mark gross
2020-01-16 22:16 ` [MODERATED] [PATCH 1/2] v3 more sampling fun 1 mark gross
2020-01-30 19:12 ` mark gross [this message]
[not found] ` <5e690bea.1c69fb81.16d6d.4b78SMTPIN_ADDED_BROKEN@mx.google.com>
2020-03-11 17:21 ` [MODERATED] " Greg KH
2020-03-11 23:09 ` mark gross
2020-03-11 20:02 ` Thomas Gleixner
2020-03-17 18:56 ` [MODERATED] " mark gross
2020-03-11 20:26 ` [PATCH 2/2] v3 more sampling fun 2 Thomas Gleixner
2020-03-11 20:38 ` [MODERATED] " Andrew Cooper
2020-03-11 23:23 ` mark gross
2020-03-12 22:04 ` mark gross
2020-03-13 15:21 ` Thomas Gleixner
2020-03-11 20:28 ` [MODERATED] Re: [PATCH 1/2] v3 more sampling fun 1 Andrew Cooper
2020-03-11 23:18 ` mark gross
2020-03-12 0:25 ` Luck, Tony
2020-03-12 1:34 ` Andrew Cooper
2020-03-12 15:25 ` Luck, Tony
2020-03-12 16:02 ` Luck, Tony
2020-03-12 16:45 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='=?utf-8?q?=3Cb3ce08567ed48062f9d1e0f166cc35afce7316af=2E158394?= =?utf-8?q?1169=2Egit=2Emgross=40linux=2Eintel=2Ecom=3E?=' \
--to=mgross@linux.intel.com \
--cc=speck@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).