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 ; 12 Mar 2020 22:04:22 -0000 Received: from mga01.intel.com ([192.55.52.88]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jCVwD-0002Wt-NZ for speck@linutronix.de; Thu, 12 Mar 2020 23:04:22 +0100 Received: from localhost (mtg-dev.jf.intel.com [10.54.74.10]) by smtp.ostc.intel.com (Postfix) with ESMTP id 4F1396367 for ; Thu, 12 Mar 2020 22:04:18 +0000 (UTC) Date: Thu, 12 Mar 2020 15:04:18 -0700 From: mark gross Subject: [MODERATED] Re: [PATCH 2/2] v3 more sampling fun 2 Message-ID: <20200312220418.GA106528@mtg-dev.jf.intel.com> Reply-To: mgross@linux.intel.com References: <87r1xyk591.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 In-Reply-To: <87r1xyk591.fsf@nanos.tec.linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Mar 11, 2020 at 09:26:18PM +0100, speck for Thomas Gleixner wrote: > speck for mark gross writes: > > 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 > > +====================================== > > I doubt that this builds w/o warnings. And right: It does now. > > Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst:4: WARNING: Title underline too short. > > SRBDS - Special Register Buffer Data Sampling > ======================================^ fixed. > > Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst:56: WARNING: Title underline too short. > > Attack scenarios > ---------------^ fixed. > > Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst:76: WARNING: Unexpected indentation. > Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst:77: WARNING: Block quote ends without a blank line; unexpected unindent. fixed. > > Sigh... > > > +SRBDS is a hardware vulnerability that allows MDS techniques to infer values > > lacks a link to the MDS documentation will fix. > > > +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. > > And what > > > + > > +When RDRAND and RDSEED instructions are used the data is moved to the core > > +through the special register mechanism. > > This sentence is not providing any new information and can be packed in > the above where you mention RDRAND, RDSEED already. EGETKEY is no instruction? added " 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 > > s/to/to the/ done. > > > +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 > > + ============= ============ ======== > > > + ============= ============ =========================== > > ditto at the top of the table. I don't understand this feedback. > > > + > > +Related CVEs > > +------------ > > + > > +The following CVE entry is related to this SRBDS issue: > > + > > + ============== ===== =================================================== > > + CVE-2020--0543 > > + ============== ===== =================================================== > > Is the void filled at some point? Working on it. > > > +Attack scenarios > > +--------------- > > +An unprivileged user can extract returned values from RDRAND and RDSEED > > +executed on another core or sibling thread using MDS techniques. > > Lacks EGETKEY again. no, egetkey is not an instruction for use outside an SGX enclave. Also, the mitigation only alows MSR control of the mitigation for RDRAND and RDSEED. EGETKEY is always mitigated. > > > + > > + > > +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. > > I seriously doubt that you ever looked at the build output of this. I can see why you doubt I ever looked at the output. FWIW I used gitlab to view the *.rst formatting and I was focused on fighting the table below to the point I missed this section. this list is fixed now. > > + > > +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 > > allows control (methinks) ok. > > > +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. > > Errm. What has this to do with the default chosen by the kernel? its a statement that if the kernel does nothing then the mitigation is in effect. thanks for the feedback. Please respond about the comment I didn't understand. --mark