304 lines · plain
1MDS - Microarchitectural Data Sampling2======================================3 4Microarchitectural Data Sampling is a hardware vulnerability which allows5unprivileged speculative access to data which is available in various CPU6internal buffers.7 8Affected processors9-------------------10 11This vulnerability affects a wide range of Intel processors. The12vulnerability is not present on:13 14 - Processors from AMD, Centaur and other non Intel vendors15 16 - Older processor models, where the CPU family is < 617 18 - Some Atoms (Bonnell, Saltwell, Goldmont, GoldmontPlus)19 20 - Intel processors which have the ARCH_CAP_MDS_NO bit set in the21 IA32_ARCH_CAPABILITIES MSR.22 23Whether a processor is affected or not can be read out from the MDS24vulnerability file in sysfs. See :ref:`mds_sys_info`.25 26Not all processors are affected by all variants of MDS, but the mitigation27is identical for all of them so the kernel treats them as a single28vulnerability.29 30Related CVEs31------------32 33The following CVE entries are related to the MDS vulnerability:34 35 ============== ===== ===================================================36 CVE-2018-12126 MSBDS Microarchitectural Store Buffer Data Sampling37 CVE-2018-12130 MFBDS Microarchitectural Fill Buffer Data Sampling38 CVE-2018-12127 MLPDS Microarchitectural Load Port Data Sampling39 CVE-2019-11091 MDSUM Microarchitectural Data Sampling Uncacheable Memory40 ============== ===== ===================================================41 42Problem43-------44 45When performing store, load, L1 refill operations, processors write data46into temporary microarchitectural structures (buffers). The data in the47buffer can be forwarded to load operations as an optimization.48 49Under certain conditions, usually a fault/assist caused by a load50operation, data unrelated to the load memory address can be speculatively51forwarded from the buffers. Because the load operation causes a fault or52assist and its result will be discarded, the forwarded data will not cause53incorrect program execution or state changes. But a malicious operation54may be able to forward this speculative data to a disclosure gadget which55allows in turn to infer the value via a cache side channel attack.56 57Because the buffers are potentially shared between Hyper-Threads cross58Hyper-Thread attacks are possible.59 60Deeper technical information is available in the MDS specific x8661architecture section: :ref:`Documentation/arch/x86/mds.rst <mds>`.62 63 64Attack scenarios65----------------66 67Attacks against the MDS vulnerabilities can be mounted from malicious non-68privileged user space applications running on hosts or guest. Malicious69guest OSes can obviously mount attacks as well.70 71Contrary to other speculation based vulnerabilities the MDS vulnerability72does not allow the attacker to control the memory target address. As a73consequence the attacks are purely sampling based, but as demonstrated with74the TLBleed attack samples can be postprocessed successfully.75 76Web-Browsers77^^^^^^^^^^^^78 79 It's unclear whether attacks through Web-Browsers are possible at80 all. The exploitation through Java-Script is considered very unlikely,81 but other widely used web technologies like Webassembly could possibly be82 abused.83 84 85.. _mds_sys_info:86 87MDS system information88-----------------------89 90The Linux kernel provides a sysfs interface to enumerate the current MDS91status of the system: whether the system is vulnerable, and which92mitigations are active. The relevant sysfs file is:93 94/sys/devices/system/cpu/vulnerabilities/mds95 96The possible values in this file are:97 98 .. list-table::99 100 * - 'Not affected'101 - The processor is not vulnerable102 * - 'Vulnerable'103 - The processor is vulnerable, but no mitigation enabled104 * - 'Vulnerable: Clear CPU buffers attempted, no microcode'105 - The processor is vulnerable but microcode is not updated. The106 mitigation is enabled on a best effort basis.107 108 If the processor is vulnerable but the availability of the microcode109 based mitigation mechanism is not advertised via CPUID, the kernel110 selects a best effort mitigation mode. This mode invokes the mitigation111 instructions without a guarantee that they clear the CPU buffers.112 113 This is done to address virtualization scenarios where the host has the114 microcode update applied, but the hypervisor is not yet updated to115 expose the CPUID to the guest. If the host has updated microcode the116 protection takes effect; otherwise a few CPU cycles are wasted117 pointlessly.118 * - 'Mitigation: Clear CPU buffers'119 - The processor is vulnerable and the CPU buffer clearing mitigation is120 enabled.121 122If the processor is vulnerable then the following information is appended123to the above information:124 125 ======================== ============================================126 'SMT vulnerable' SMT is enabled127 'SMT mitigated' SMT is enabled and mitigated128 'SMT disabled' SMT is disabled129 'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown130 ======================== ============================================131 132Mitigation mechanism133-------------------------134 135The kernel detects the affected CPUs and the presence of the microcode136which is required.137 138If a CPU is affected and the microcode is available, then the kernel139enables the mitigation by default. The mitigation can be controlled at boot140time via a kernel command line option. See141:ref:`mds_mitigation_control_command_line`.142 143.. _cpu_buffer_clear:144 145CPU buffer clearing146^^^^^^^^^^^^^^^^^^^147 148 The mitigation for MDS clears the affected CPU buffers on return to user149 space and when entering a guest.150 151 If SMT is enabled it also clears the buffers on idle entry when the CPU152 is only affected by MSBDS and not any other MDS variant, because the153 other variants cannot be protected against cross Hyper-Thread attacks.154 155 For CPUs which are only affected by MSBDS the user space, guest and idle156 transition mitigations are sufficient and SMT is not affected.157 158.. _virt_mechanism:159 160Virtualization mitigation161^^^^^^^^^^^^^^^^^^^^^^^^^162 163 The protection for host to guest transition depends on the L1TF164 vulnerability of the CPU:165 166 - CPU is affected by L1TF:167 168 If the L1D flush mitigation is enabled and up to date microcode is169 available, the L1D flush mitigation is automatically protecting the170 guest transition.171 172 If the L1D flush mitigation is disabled then the MDS mitigation is173 invoked explicit when the host MDS mitigation is enabled.174 175 For details on L1TF and virtualization see:176 :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <mitigation_control_kvm>`.177 178 - CPU is not affected by L1TF:179 180 CPU buffers are flushed before entering the guest when the host MDS181 mitigation is enabled.182 183 The resulting MDS protection matrix for the host to guest transition:184 185 ============ ===== ============= ============ =================186 L1TF MDS VMX-L1FLUSH Host MDS MDS-State187 188 Don't care No Don't care N/A Not affected189 190 Yes Yes Disabled Off Vulnerable191 192 Yes Yes Disabled Full Mitigated193 194 Yes Yes Enabled Don't care Mitigated195 196 No Yes N/A Off Vulnerable197 198 No Yes N/A Full Mitigated199 ============ ===== ============= ============ =================200 201 This only covers the host to guest transition, i.e. prevents leakage from202 host to guest, but does not protect the guest internally. Guests need to203 have their own protections.204 205.. _xeon_phi:206 207XEON PHI specific considerations208^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^209 210 The XEON PHI processor family is affected by MSBDS which can be exploited211 cross Hyper-Threads when entering idle states. Some XEON PHI variants allow212 to use MWAIT in user space (Ring 3) which opens an potential attack vector213 for malicious user space. The exposure can be disabled on the kernel214 command line with the 'ring3mwait=disable' command line option.215 216 XEON PHI is not affected by the other MDS variants and MSBDS is mitigated217 before the CPU enters a idle state. As XEON PHI is not affected by L1TF218 either disabling SMT is not required for full protection.219 220.. _mds_smt_control:221 222SMT control223^^^^^^^^^^^224 225 All MDS variants except MSBDS can be attacked cross Hyper-Threads. That226 means on CPUs which are affected by MFBDS or MLPDS it is necessary to227 disable SMT for full protection. These are most of the affected CPUs; the228 exception is XEON PHI, see :ref:`xeon_phi`.229 230 Disabling SMT can have a significant performance impact, but the impact231 depends on the type of workloads.232 233 See the relevant chapter in the L1TF mitigation documentation for details:234 :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst <smt_control>`.235 236 237.. _mds_mitigation_control_command_line:238 239Mitigation control on the kernel command line240---------------------------------------------241 242The kernel command line allows to control the MDS mitigations at boot243time with the option "mds=". The valid arguments for this option are:244 245 ============ =============================================================246 full If the CPU is vulnerable, enable all available mitigations247 for the MDS vulnerability, CPU buffer clearing on exit to248 userspace and when entering a VM. Idle transitions are249 protected as well if SMT is enabled.250 251 It does not automatically disable SMT.252 253 full,nosmt The same as mds=full, with SMT disabled on vulnerable254 CPUs. This is the complete mitigation.255 256 off Disables MDS mitigations completely.257 258 ============ =============================================================259 260Not specifying this option is equivalent to "mds=full". For processors261that are affected by both TAA (TSX Asynchronous Abort) and MDS,262specifying just "mds=off" without an accompanying "tsx_async_abort=off"263will have no effect as the same mitigation is used for both264vulnerabilities.265 266Mitigation selection guide267--------------------------268 2691. Trusted userspace270^^^^^^^^^^^^^^^^^^^^271 272 If all userspace applications are from a trusted source and do not273 execute untrusted code which is supplied externally, then the mitigation274 can be disabled.275 276 2772. Virtualization with trusted guests278^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^279 280 The same considerations as above versus trusted user space apply.281 2823. Virtualization with untrusted guests283^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^284 285 The protection depends on the state of the L1TF mitigations.286 See :ref:`virt_mechanism`.287 288 If the MDS mitigation is enabled and SMT is disabled, guest to host and289 guest to guest attacks are prevented.290 291.. _mds_default_mitigations:292 293Default mitigations294-------------------295 296 The kernel default mitigations for vulnerable processors are:297 298 - Enable CPU buffer clearing299 300 The kernel does not by default enforce the disabling of SMT, which leaves301 SMT systems vulnerable when running untrusted code. The same rationale as302 for L1TF applies.303 See :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <default_mitigations>`.304