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 ; 11 Mar 2020 23:23:41 -0000 Received: from mga14.intel.com ([192.55.52.115]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1jCAhO-0004jA-VQ for speck@linutronix.de; Thu, 12 Mar 2020 00:23:39 +0100 Received: from localhost (mtg-dev.jf.intel.com [10.54.74.10]) by smtp.ostc.intel.com (Postfix) with ESMTP id 7DF706367 for ; Wed, 11 Mar 2020 23:23:36 +0000 (UTC) Date: Wed, 11 Mar 2020 16:23:36 -0700 From: mark gross Subject: [MODERATED] Re: [PATCH 2/2] v3 more sampling fun 2 Message-ID: <20200311232336.GC78230@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: Thanks for the valueble feedback. I'll go over it in more detail tomorrow. But, one thing I want to point out is that EGETKEY is always mitigate and only RDRAND and RDSEED can have the mitigation disabled. This is the first time I've worked with the Documentation. I did build it but I only looked to see if it completed :( --mark 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: > > Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst:4: WARNING: Title underline too short. > > SRBDS - Special Register Buffer Data Sampling > ======================================^ > > Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst:56: WARNING: Title underline too short. > > Attack scenarios > ---------------^ > > 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. > > Sigh... > > > +SRBDS is a hardware vulnerability that allows MDS techniques to infer values > > lacks a link to the MDS documentation > > > +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? > > > +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/ > > > +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. > > > + > > +Related CVEs > > +------------ > > + > > +The following CVE entry is related to this SRBDS issue: > > + > > + ============== ===== =================================================== > > + CVE-2020--0543 > > + ============== ===== =================================================== > > Is the void filled at some point? > > > +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. > > > + > > + > > +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. > > > + > > +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) > > > +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? > > Thanks, > > tglx