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