1MDS - Microarchitectural Data Sampling 2====================================== 3 4Microarchitectural Data Sampling is a hardware vulnerability which allows 5unprivileged speculative access to data which is available in various CPU 6internal buffers. 7 8Affected processors 9------------------- 10 11This vulnerability affects a wide range of Intel processors. The 12vulnerability is not present on: 13 14 - Processors from AMD, Centaur and other non Intel vendors 15 16 - Older processor models, where the CPU family is < 6 17 18 - Some Atoms (Bonnell, Saltwell, Goldmont, GoldmontPlus) 19 20 - Intel processors which have the ARCH_CAP_MDS_NO bit set in the 21 IA32_ARCH_CAPABILITIES MSR. 22 23Whether a processor is affected or not can be read out from the MDS 24vulnerability file in sysfs. See :ref:`mds_sys_info`. 25 26Not all processors are affected by all variants of MDS, but the mitigation 27is identical for all of them so the kernel treats them as a single 28vulnerability. 29 30Related CVEs 31------------ 32 33The following CVE entries are related to the MDS vulnerability: 34 35 ============== ===== =================================================== 36 CVE-2018-12126 MSBDS Microarchitectural Store Buffer Data Sampling 37 CVE-2018-12130 MFBDS Microarchitectural Fill Buffer Data Sampling 38 CVE-2018-12127 MLPDS Microarchitectural Load Port Data Sampling 39 CVE-2019-11091 MDSUM Microarchitectural Data Sampling Uncacheable Memory 40 ============== ===== =================================================== 41 42Problem 43------- 44 45When performing store, load, L1 refill operations, processors write data 46into temporary microarchitectural structures (buffers). The data in the 47buffer can be forwarded to load operations as an optimization. 48 49Under certain conditions, usually a fault/assist caused by a load 50operation, data unrelated to the load memory address can be speculatively 51forwarded from the buffers. Because the load operation causes a fault or 52assist and its result will be discarded, the forwarded data will not cause 53incorrect program execution or state changes. But a malicious operation 54may be able to forward this speculative data to a disclosure gadget which 55allows in turn to infer the value via a cache side channel attack. 56 57Because the buffers are potentially shared between Hyper-Threads cross 58Hyper-Thread attacks are possible. 59 60Deeper technical information is available in the MDS specific x86 61architecture section: :ref:`Documentation/arch/x86/mds.rst <mds>`. 62 63 64Attack scenarios 65---------------- 66 67Attacks against the MDS vulnerabilities can be mounted from malicious non- 68privileged user space applications running on hosts or guest. Malicious 69guest OSes can obviously mount attacks as well. 70 71Contrary to other speculation based vulnerabilities the MDS vulnerability 72does not allow the attacker to control the memory target address. As a 73consequence the attacks are purely sampling based, but as demonstrated with 74the TLBleed attack samples can be postprocessed successfully. 75 76Web-Browsers 77^^^^^^^^^^^^ 78 79 It's unclear whether attacks through Web-Browsers are possible at 80 all. The exploitation through Java-Script is considered very unlikely, 81 but other widely used web technologies like Webassembly could possibly be 82 abused. 83 84 85.. _mds_sys_info: 86 87MDS system information 88----------------------- 89 90The Linux kernel provides a sysfs interface to enumerate the current MDS 91status of the system: whether the system is vulnerable, and which 92mitigations are active. The relevant sysfs file is: 93 94/sys/devices/system/cpu/vulnerabilities/mds 95 96The possible values in this file are: 97 98 .. list-table:: 99 100 * - 'Not affected' 101 - The processor is not vulnerable 102 * - 'Vulnerable' 103 - The processor is vulnerable, but no mitigation enabled 104 * - 'Vulnerable: Clear CPU buffers attempted, no microcode' 105 - The processor is vulnerable but microcode is not updated. The 106 mitigation is enabled on a best effort basis. 107 108 If the processor is vulnerable but the availability of the microcode 109 based mitigation mechanism is not advertised via CPUID, the kernel 110 selects a best effort mitigation mode. This mode invokes the mitigation 111 instructions without a guarantee that they clear the CPU buffers. 112 113 This is done to address virtualization scenarios where the host has the 114 microcode update applied, but the hypervisor is not yet updated to 115 expose the CPUID to the guest. If the host has updated microcode the 116 protection takes effect; otherwise a few CPU cycles are wasted 117 pointlessly. 118 * - 'Mitigation: Clear CPU buffers' 119 - The processor is vulnerable and the CPU buffer clearing mitigation is 120 enabled. 121 122If the processor is vulnerable then the following information is appended 123to the above information: 124 125 ======================== ============================================ 126 'SMT vulnerable' SMT is enabled 127 'SMT mitigated' SMT is enabled and mitigated 128 'SMT disabled' SMT is disabled 129 'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown 130 ======================== ============================================ 131 132Mitigation mechanism 133------------------------- 134 135The kernel detects the affected CPUs and the presence of the microcode 136which is required. 137 138If a CPU is affected and the microcode is available, then the kernel 139enables the mitigation by default. The mitigation can be controlled at boot 140time via a kernel command line option. See 141:ref:`mds_mitigation_control_command_line`. 142 143.. _cpu_buffer_clear: 144 145CPU buffer clearing 146^^^^^^^^^^^^^^^^^^^ 147 148 The mitigation for MDS clears the affected CPU buffers on return to user 149 space and when entering a guest. 150 151 If SMT is enabled it also clears the buffers on idle entry when the CPU 152 is only affected by MSBDS and not any other MDS variant, because the 153 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 idle 156 transition mitigations are sufficient and SMT is not affected. 157 158.. _virt_mechanism: 159 160Virtualization mitigation 161^^^^^^^^^^^^^^^^^^^^^^^^^ 162 163 The protection for host to guest transition depends on the L1TF 164 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 is 169 available, the L1D flush mitigation is automatically protecting the 170 guest transition. 171 172 If the L1D flush mitigation is disabled then the MDS mitigation is 173 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 MDS 181 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-State 187 188 Don't care No Don't care N/A Not affected 189 190 Yes Yes Disabled Off Vulnerable 191 192 Yes Yes Disabled Full Mitigated 193 194 Yes Yes Enabled Don't care Mitigated 195 196 No Yes N/A Off Vulnerable 197 198 No Yes N/A Full Mitigated 199 ============ ===== ============= ============ ================= 200 201 This only covers the host to guest transition, i.e. prevents leakage from 202 host to guest, but does not protect the guest internally. Guests need to 203 have their own protections. 204 205.. _xeon_phi: 206 207XEON PHI specific considerations 208^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 209 210 The XEON PHI processor family is affected by MSBDS which can be exploited 211 cross Hyper-Threads when entering idle states. Some XEON PHI variants allow 212 to use MWAIT in user space (Ring 3) which opens an potential attack vector 213 for malicious user space. The exposure can be disabled on the kernel 214 command line with the 'ring3mwait=disable' command line option. 215 216 XEON PHI is not affected by the other MDS variants and MSBDS is mitigated 217 before the CPU enters a idle state. As XEON PHI is not affected by L1TF 218 either disabling SMT is not required for full protection. 219 220.. _mds_smt_control: 221 222SMT control 223^^^^^^^^^^^ 224 225 All MDS variants except MSBDS can be attacked cross Hyper-Threads. That 226 means on CPUs which are affected by MFBDS or MLPDS it is necessary to 227 disable SMT for full protection. These are most of the affected CPUs; the 228 exception is XEON PHI, see :ref:`xeon_phi`. 229 230 Disabling SMT can have a significant performance impact, but the impact 231 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 line 240--------------------------------------------- 241 242The kernel command line allows to control the MDS mitigations at boot 243time with the option "mds=". The valid arguments for this option are: 244 245 ============ ============================================================= 246 full If the CPU is vulnerable, enable all available mitigations 247 for the MDS vulnerability, CPU buffer clearing on exit to 248 userspace and when entering a VM. Idle transitions are 249 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 vulnerable 254 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 processors 261that 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 both 264vulnerabilities. 265 266Mitigation selection guide 267-------------------------- 268 2691. Trusted userspace 270^^^^^^^^^^^^^^^^^^^^ 271 272 If all userspace applications are from a trusted source and do not 273 execute untrusted code which is supplied externally, then the mitigation 274 can be disabled. 275 276 2772. Virtualization with trusted guests 278^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 279 280 The same considerations as above versus trusted user space apply. 281 2823. Virtualization with untrusted guests 283^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 and 289 guest to guest attacks are prevented. 290 291.. _mds_default_mitigations: 292 293Default mitigations 294------------------- 295 296 The kernel default mitigations for vulnerable processors are: 297 298 - Enable CPU buffer clearing 299 300 The kernel does not by default enforce the disabling of SMT, which leaves 301 SMT systems vulnerable when running untrusted code. The same rationale as 302 for L1TF applies. 303 See :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <default_mitigations>`. 304