[MODERATED] Re: [patch V4 11/11] Documentation: Add MDS vulnerability documentation

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Feb 22, 2019 at 11:24:29PM +0100, speck for Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> 
> Add the initial MDS vulnerability documentation.
> 
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> 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 <gregkh@linuxfoundation.org>