[MODERATED] Re: [patch 8/8] MDS basics 8

On 19/02/2019 12:44, speck for Thomas Gleixner wrote:
> --- /dev/null
> +++ b/Documentation/admin-guide/hw-vuln/mds.rst
> @@ -0,0 +1,230 @@
> +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.

Strictly speaking, it is a group of related vulnerabilities.

The distinction is further complicated because some processors are only
affected by a subset of the group.

> +
> +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
> +   ==============  =====  ==============================================

Any chance of listing in CVE order?  Something feels weird having it
like this.

> +
> +Problem
> +-------
> +
> +When performing store, load, L1 refill operations, processors write data

Possibly just limit it to loads and stores?  From what I've been told,
the fill buffers get all data exiting the pipeline (including WC and UC)
and the L1 refill bit is just one aspect of their functionality.

> +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 programm execution or state changes. But a malicious operation

Hmm - Today I learnt that there is a difference between the English and
German spelling of programm.

> +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.

Its not restricted to cache side channels.  There are other options
available for a sufficiently crafty attacker.

> +
> +Because the buffers are potentially shared between Hyper-Threads cross
> +Hyper-Thread attacks may be possible.

The cooperating-hyperthread attack has been demonstrated in practice.

Another piece of information which may not have filtered through from
Keybase a while ago is (an indirect report) of a researcher's
description of their PoC against Linux.

One thread sits and makes setrlimit() syscalls with a userspace pointer
to train the branch predictor to strongly take the copy_from_user()
path.  It then switches the pointer to a kernel address of interest for
the next syscall.

Speculation takes the strongly taken path, reads from kernel space and
writes into the local buffer (also in kernel space), but this uses a
fill buffer in the pipeline.  The other thread can snatch the data by
repeatedly sampling the fill buffers.

The data rate wasn't very high (6 bytes per second) when trying to leak
a 4k page containing known ASCII text, but it clearly demonstrates that
the attack is possible.

This particular PoC also depends on SMAP being disabled, as STAC/CLAC
instructions have lfence properties, but this is an implementation
detail rather than an architectural guarantee.  There are also plenty of
opportunities to pull this attack off outside of a STAC/CLAC pair.

> +
> +As the buffer sizes are smaller than the L1 cache, which was target of
> +previous vulnerabilities, e.g. Meltdown, L1TF, the vulnerability is harder
> +to exploit than with those attack vectors.
> +
> +
> +Attack scenarios
> +----------------
> +
> +  TBD
> +
> +.. _mds_sys_info:
> +
> +MDS system information
> +-----------------------
> +
> +The Linux kernel provides a sysfs interface to enumerate the current MDS
> +status of the system: whether the system is vulnerable, and which
> +mitigations are active. The relevant sysfs file is:
> +
> +/sys/devices/system/cpu/vulnerabilities/mds
> +
> +The possible values in this file are:
> +
> +  ==============================   ====================================
> +  'Not affected'		   The processor is not vulnerable
> +  'Vulnerable'			   The processor is vulnerable, but no
> +				   mitigation enabled
> +  'Mitigation: CPU buffer clear'   The processor is vulnerable and the
> +				   CPU buffer clearing mitigation is
> +				   enabled.
> +  ==============================   ====================================
> +
> +If the processor is vulnerable then the following information is appended
> +to the above information:
> +
> +  - SMT status:
> +
> +    ========================  ============================================
> +    'SMT vulnerable'          SMT is enabled
> +    'SMT disabled'            SMT is disabled
> +    'SMT Host state unknown'  Kernel runs in a VM, Host SMT state unknown
> +    ========================  ============================================

To the virtualisation side of things, in Xen we are working to ensure
that the reported topology is accurate and is scheduled in a safe way.

There is a proposed extension to the HyperV Viridian specification,
which will be a "topology can be trusted for safety" bit, and Xen will
be gaining a similar mechanism as soon as we've made it work.

> +
> +
> +Mitigation mechanism
> +-------------------------
> +
> +The kernel detects the affected CPUs and the presence of the microcode
> +which is required.
> +
> +If a CPU is affected and the microcode is available, then the kernel
> +enables the mitigation by default. The mitigation can be controlled at boot
> +time via a kernel command line option. See
> +:ref:`mds_mitigation_control_command_line`.
> +
> +.. _cpu_buffer_clear_full:
> +
> +Unconditional CPU buffer clearing
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +   The mitigation for MDS clears the affected CPU buffers unconditionally
> +   on return to user space and when entering a guest.
> +
> +   If SMT is enabled it also clears the buffers on idle entry, but that's
> +   not a sufficient SMT protection for all MDS variants; it covers solely
> +   MSBDS.
> +
> +.. _virt_mechanism:
> +
> +Virtualization mitigation
> +^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +   If the CPU is also affected by L1TF and the L1D flush mitigation is
> +   enabled and up to date microcode is available, the L1D flush mitigation
> +   is automatically protecting the guest transition. For details on L1TF
> +   and virtualization see:
> +   :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <mitigation_control_kvm>`.

Spurious double slash ?

~Andrew