From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 23 Feb 2019 09:58:37 -0000 Received: from mail.kernel.org ([198.145.29.99]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gxU4p-0006Wf-L1 for speck@linutronix.de; Sat, 23 Feb 2019 10:58:36 +0100 Date: Sat, 23 Feb 2019 10:58:25 +0100 From: Greg KH Subject: [MODERATED] Re: [patch V4 11/11] Documentation: Add MDS vulnerability documentation Message-ID: <20190223095825.GC11354@kroah.com> References: <20190222222418.405369026@linutronix.de> <20190222224150.075637764@linutronix.de> MIME-Version: 1.0 In-Reply-To: <20190222224150.075637764@linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Feb 22, 2019 at 11:24:29PM +0100, speck for Thomas Gleixner wrote: > From: Thomas Gleixner > > Add the initial MDS vulnerability documentation. > > Signed-off-by: Thomas Gleixner > --- > V1 --> V4: Added the missing pieces > --- > Documentation/admin-guide/hw-vuln/index.rst | 1 > Documentation/admin-guide/hw-vuln/l1tf.rst | 1 > Documentation/admin-guide/hw-vuln/mds.rst | 258 ++++++++++++++++++++++++++++ > 3 files changed, 260 insertions(+) > > --- a/Documentation/admin-guide/hw-vuln/index.rst > +++ b/Documentation/admin-guide/hw-vuln/index.rst > @@ -10,3 +10,4 @@ are configurable at compile, boot or run > :maxdepth: 1 > > l1tf > + mds > --- a/Documentation/admin-guide/hw-vuln/l1tf.rst > +++ b/Documentation/admin-guide/hw-vuln/l1tf.rst > @@ -445,6 +445,7 @@ The default is 'cond'. If 'l1tf=full,for > line, then 'always' is enforced and the kvm-intel.vmentry_l1d_flush > module parameter is ignored and writes to the sysfs file are rejected. > > +.. _mitigation_selection: > > Mitigation selection guide > -------------------------- > --- /dev/null > +++ b/Documentation/admin-guide/hw-vuln/mds.rst > @@ -0,0 +1,258 @@ > +MDS - Microarchitectural Data Sampling > +====================================== > + > +Microarchitectural Data Sampling is a hardware vulnerability which allows > +unprivileged speculative access to data which is available in various CPU > +internal buffers. > + > +Affected processors > +------------------- > + > +This vulnerability affects a wide range of Intel processors. The > +vulnerability is not present on: > + > + - Processors from AMD, Centaur and other non Intel vendors > + > + - Older processor models, where the CPU family is < 6 > + > + - Some Atoms (Bonnell, Saltwell, Goldmont, GoldmontPlus) > + > + - Intel processors which have the ARCH_CAP_MDS_NO bit set in the > + IA32_ARCH_CAPABILITIES MSR. > + > +Whether a processor is affected or not can be read out from the MDS > +vulnerability file in sysfs. See :ref:`mds_sys_info`. > + > +Related CVEs > +------------ > + > +The following CVE entries are related to the MDS vulnerability: > + > + ============== ===== ============================================== > + CVE-2018-12126 MSBDS Microarchitectural Store Buffer Data Sampling > + CVE-2018-12130 MFBDS Microarchitectural Fill Buffer Data Sampling > + CVE-2018-12127 MLPDS Microarchitectural Load Port Data Sampling > + ============== ===== ============================================== > + > +Problem > +------- > + > +When performing store, load, L1 refill operations, processors write data > +into temporary microarchitectural structures (buffers). The data in the > +buffer can be forwarded to load operations as an optimization. > + > +Under certain conditions, usually a fault/assist caused by a load > +operation, data unrelated to the load memory address can be speculatively > +forwarded from the buffers. Because the load operation causes a fault or > +assist and its result will be discarded, the forwarded data will not cause > +incorrect program execution or state changes. But a malicious operation > +may be able to forward this speculative data to a disclosure gadget which > +allows in turn to infer the value via a cache side channel attack. > + > +Because the buffers are potentially shared between Hyper-Threads cross > +Hyper-Thread attacks may be possible. Shouldn't this be "are possible."? As "proof" of this, some of the Linux distros, and a few other operating systems, told Intel last week that they were going to be disabling hyperthreading on their systems. Some distros/OSs were only going to do that on a "new install", but others can't really tell the difference between an upgrade and new install, so were going to do it by default. Theo was right, for all the wrong reasons :) Anyway, good documentation, even if you don't want to change that sentance, it looks fine to me: Reviewed-by: Greg Kroah-Hartman