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 ; 19 Feb 2019 13:42:11 -0000 Received: from localhost ([127.0.0.1] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtp (Exim 4.80) (envelope-from ) id 1gw5b6-0004Bg-2R for speck@linutronix.de; Tue, 19 Feb 2019 14:38:08 +0100 Message-Id: <20190219125346.509128952@linutronix.de> Date: Tue, 19 Feb 2019 13:44:14 +0100 From: Thomas Gleixner References: <20190219124406.449727187@linutronix.de> MIME-Version: 1.0 Subject: [patch 8/8] MDS basics 8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: Subject: [patch 8/8] Documentation: Add MDS vulnerability documentation From: Thomas Gleixner Add the initial MDS vulnerability documentation. Still needs a lot of work.... Signed-off-by: Thomas Gleixner --- Documentation/admin-guide/hw-vuln/index.rst | 1 Documentation/admin-guide/hw-vuln/l1tf.rst | 1 Documentation/admin-guide/hw-vuln/mds.rst | 230 ++++++++++++++++++++++++++++ 3 files changed, 232 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,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. + +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 programm 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. + +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 + ======================== ============================================ + + +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 `. + + If the L1D flush mitigation is disabled or the microcode is not + available the guest transition is unprotected. + +.. _xeon_phi: + +XEON PHI specific considerations +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + The XEON PHI processor familiy is affected by MSBDS which can be + exploited cross Hyper-Threads when entering idle states. Some XEON PHI + variants allow to use MWAIT in user space (Ring 3) which opens an + potential attack vector for malicious user space. The exposure can be + disabled on the kernel command line with the 'ring3mwait=disable' + command line option. + +.. _mds_smt_control: + +SMT control +^^^^^^^^^^^ + + To prevent the SMT issues of MDS it might be necessary to disable SMT + completely. Disabling SMT can have a significant performance impact, but + the impact depends on the type of workloads. + + See the relevant chapter in the L1TF mitigation documentation for details: + :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst `. + +.. _mds_mitigation_control_command_line: + +Mitigation control on the kernel command line +--------------------------------------------- + +The kernel command line allows to control the MDS mitigations at boot +time with the option "mds=". The valid arguments for this option are: + + ============ ============================================================= + full Provides all available mitigations for the MDS vulnerability + vulnerability, unconditional CPU buffer clearing on exit to + userspace and when entering a VM. + + It does not automatically disable SMT. + + off Disables MDS mitigations completely. + + ============ ============================================================= + +The default is 'full'. For details see :ref:`cpu_buffer_clear_full`. + + +Mitigation selection guide +-------------------------- + +1. Trusted userspace +^^^^^^^^^^^^^^^^^^^^ + + If all userspace applications are from a trusted source and do not + execute untrusted code which is supplied externally, then the mitigation + can be disabled. + + +2. Virtualization with trusted guests +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + The same considerations as above versus trusted user space apply. See + also: :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst `. + + +3. Virtualization with untrusted guests +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + See :ref:`virt_mechanism`. + +3.4. Nested virtual machines +"""""""""""""""""""""""""""" + +When nested virtualization is in use, three operating systems are involved: +the bare metal hypervisor, the nested hypervisor and the nested virtual +machine. VMENTER operations from the nested hypervisor into the nested +guest will always be processed by the bare metal hypervisor. If KVM is the +bare metal hypervisor it will: + + - Invoke the enabled mitigation mechanism, L1D flush or CPU buffer + clearing on every switch from the nested hypervisor to the nested + virtual machine. + +.. _mds_default_mitigations: + +Default mitigations +------------------- + + The kernel default mitigations for vulnerable processors are: + + - Enable CPU buffer clearing + + The kernel does not by default enforce the disabling of SMT, which leaves + SMT systems vulnerable when running untrusted code. The same rationale as + for L1TF applies. + See :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst `.