All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, Mark Gross <mgross@linux.intel.com>,
	Borislav Petkov <bp@suse.de>, Tony Luck <tony.luck@intel.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH 4.4 33/36] x86/speculation: Add SRBDS vulnerability and mitigation documentation
Date: Tue,  9 Jun 2020 19:44:33 +0200	[thread overview]
Message-ID: <20200609173935.644693109@linuxfoundation.org> (raw)
In-Reply-To: <20200609173933.288044334@linuxfoundation.org>

From: Mark Gross <mgross@linux.intel.com>

commit 7222a1b5b87417f22265c92deea76a6aecd0fb0f upstream

Add documentation for the SRBDS vulnerability and its mitigation.

 [ bp: Massage.
   jpoimboe: sysfs table strings. ]

Signed-off-by: Mark Gross <mgross@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 Documentation/hw-vuln/special-register-buffer-data-sampling.rst |  148 ++++++++++
 1 file changed, 148 insertions(+)
 create mode 100644 Documentation/hw-vuln/special-register-buffer-data-sampling.rst

--- /dev/null
+++ b/Documentation/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 may
+be affected.
+
+A processor is affected by SRBDS if its Family_Model and stepping is
+in the following list, with the exception of the listed processors
+exporting MDS_NO while Intel TSX is available yet not enabled. The
+latter class of processors are only affected when Intel TSX is enabled
+by software using TSX_CTRL_MSR otherwise they are not affected.
+
+  =============  ============  ========
+  common name    Family_Model  Stepping
+  =============  ============  ========
+  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        <=0xC
+
+  Kabylake       06_9EH        <=0xD
+  =============  ============  ========
+
+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 values returned 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 instructions, 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 instructions 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 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
+ Mitigation: Microcode          Processor is vulnerable and mitigation is in
+                                effect.
+ Mitigation: TSX disabled       Processor is only vulnerable when TSX is
+                                enabled while this system was booted with TSX
+                                disabled.
+ Unknown: Dependent on
+ hypervisor status              Running on virtual guest processor that is
+                                affected but with no way to know if host
+                                processor is mitigated or vulnerable.
+ ============================== =============================================
+
+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.



  parent reply	other threads:[~2020-06-09 17:47 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-09 17:44 [PATCH 4.4 00/36] 4.4.227-rc1 review Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 01/36] scsi: scsi_devinfo: fixup string compare Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 02/36] usb: gadget: f_uac2: fix error handling in afunc_bind (again) Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 03/36] platform/x86: acer-wmi: setup accelerometer when ACPI device was found Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 04/36] esp6: fix memleak on error path in esp6_input Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 05/36] IB/mlx4: Fix an error handling path in mlx4_ib_rereg_user_mr() Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 06/36] ALSA: hda - No loopback on ALC299 codec Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 07/36] spi: dw: use "smp_mb()" to avoid sending spi data error Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 08/36] s390/ftrace: save traced function caller Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 09/36] ARC: Fix ICCM & DCCM runtime size checks Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 10/36] x86/mmiotrace: Use cpumask_available() for cpumask_var_t variables Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 11/36] net: bmac: Fix read of MAC address from ROM Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 12/36] net/ethernet/freescale: rework quiesce/activate for ucc_geth Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 13/36] net: ethernet: stmmac: Enable interface clocks on probe for IPQ806x Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 14/36] pppoe: only process PADT targeted at local interfaces Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 15/36] mmc: fix compilation of user API Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 16/36] slcan: Fix double-free on slcan_open() error path Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 17/36] slip: not call free_netdev before rtnl_unlock in slip_open Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 18/36] scsi: ufs: Release clock if DMA map fails Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 19/36] devinet: fix memleak in inetdev_init() Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 20/36] NFC: st21nfca: add missed kfree_skb() in an error path Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 21/36] vsock: fix timeout in vsock_accept() Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 22/36] l2tp: add sk_family checks to l2tp_validate_socket Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 23/36] l2tp: do not use inet_hash()/inet_unhash() Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 24/36] USB: serial: qcserial: add DW5816e QDL support Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 25/36] USB: serial: usb_wwan: do not resubmit rx urb on fatal errors Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 26/36] USB: serial: option: add Telit LE910C1-EUX compositions Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 27/36] vt: keyboard: avoid signed integer overflow in k_ascii Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 28/36] staging: rtl8712: Fix IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 29/36] x86/cpu: Rename cpu_data.x86_mask to cpu_data.x86_stepping Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 30/36] x86/cpu: Add a steppings field to struct x86_cpu_id Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 31/36] x86/cpu: Add table argument to cpu_matches() Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 32/36] x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation Greg Kroah-Hartman
2020-06-09 17:44 ` Greg Kroah-Hartman [this message]
2020-06-09 17:44 ` [PATCH 4.4 34/36] x86/speculation: Add Ivy Bridge to affected list Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 35/36] iio: vcnl4000: Fix i2c swapped word reading Greg Kroah-Hartman
2020-06-09 17:44 ` [PATCH 4.4 36/36] uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned Greg Kroah-Hartman

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=20200609173935.644693109@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=bp@suse.de \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgross@linux.intel.com \
    --cc=stable@vger.kernel.org \
    --cc=tony.luck@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.