From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 27 Mar 2020 16:28:44 -0000 Received: from mga05.intel.com ([192.55.52.43]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jHrqd-0001u4-7b for speck@linutronix.de; Fri, 27 Mar 2020 17:28:43 +0100 Received: from localhost (mtg-dev.jf.intel.com [10.54.74.10]) by smtp.ostc.intel.com (Postfix) with ESMTP id 494E7636D for ; Fri, 27 Mar 2020 16:28:40 +0000 (UTC) Date: Fri, 27 Mar 2020 09:28:40 -0700 From: mark gross Subject: [MODERATED] Re: [PATCH 3/3] v4 more sampling fun 3 Message-ID: <20200327162840.GB2707@mtg-dev.jf.intel.com> Reply-To: mgross@linux.intel.com References: <20200326032521.mex4v6er77nlbgft@treble> MIME-Version: 1.0 In-Reply-To: <20200326032521.mex4v6er77nlbgft@treble> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Mar 25, 2020 at 10:25:21PM -0500, speck for Josh Poimboeuf wrote: > On Thu, Jan 30, 2020 at 11:12:02AM -0800, speck for mark gross wrote: > > From: mark gross > > Subject: [PATCH 3/3] x86/speculation: SRBDS vulnerability and mitigation > > documentation > > > > Add documentation for the SRBDS vulnerability and its mitigation. > > > > Reviewed-by: Tony Luck > > Signed-off-by: Mark Gross > > --- > > 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 > > > > 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..1fae5f455eb8 > > --- /dev/null > > +++ b/Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst > > @@ -0,0 +1,150 @@ > > +.. 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 Intels evaluation, > > Intel's Thanks! > > > +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 > > +---------------- > > +An unprivileged user can extract returned values from RDRAND and RDSEED > > +executed on another core or sibling thread using MDS techniques. > > + > > + > > +Mitigtion mechanism > > Mitigation Thanks! > > > +------------------- > > +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: > > + > > + ============= ============================================================= > > + off This option disables SRBS mitigation for RDRAND and RDSEED on > > + affected platforms. > > + ============= ============================================================= > > + > > +SRBS System Information > > SRBDS Thanks! > > > +----------------------- > > +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 I'll make them match. FWIW I'd rather have srbds be the file name. > > + > > +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. > > Run-on sentence... How about?: This new microcode serializes processor access during execution of RDRAND, RDSEED ensures that the shared buffer is overwritten before it is released for reuse. thanks, --mark > > -- > Josh