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/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 priviledged 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.
106 mitigation is enabled on a best effor <<
107 106
108 If the processor is vulnerable but th !! 107 The mitigation is enabled on a best effort basis. See :ref:`vmwerv`
109 based mitigation mechanism is not adv <<
110 selects a best effort mitigation mode <<
111 instructions without a guarantee that <<
112 <<
113 This is done to address virtualizatio <<
114 microcode update applied, but the hyp <<
115 expose the CPUID to the guest. If the <<
116 protection takes effect; otherwise a <<
117 pointlessly. <<
118 * - 'Mitigation: Clear CPU buffers' 108 * - 'Mitigation: Clear CPU buffers'
119 - The processor is vulnerable and the C 109 - The processor is vulnerable and the CPU buffer clearing mitigation is
120 enabled. 110 enabled.
121 111
122 If the processor is vulnerable then the follow 112 If the processor is vulnerable then the following information is appended
123 to the above information: 113 to the above information:
124 114
125 ======================== ================ 115 ======================== ============================================
126 'SMT vulnerable' SMT is enabled 116 'SMT vulnerable' SMT is enabled
127 'SMT mitigated' SMT is enabled a 117 'SMT mitigated' SMT is enabled and mitigated
128 'SMT disabled' SMT is disabled 118 'SMT disabled' SMT is disabled
129 'SMT Host state unknown' Kernel runs in a 119 'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown
130 ======================== ================ 120 ======================== ============================================
>> 121
>> 122 .. _vmwerv:
>> 123
>> 124 Best effort mitigation mode
>> 125 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 126
>> 127 If the processor is vulnerable, but the availability of the microcode based
>> 128 mitigation mechanism is not advertised via CPUID the kernel selects a best
>> 129 effort mitigation mode. This mode invokes the mitigation instructions
>> 130 without a guarantee that they clear the CPU buffers.
>> 131
>> 132 This is done to address virtualization scenarios where the host has the
>> 133 microcode update applied, but the hypervisor is not yet updated to expose
>> 134 the CPUID to the guest. If the host has updated microcode the protection
>> 135 takes effect otherwise a few cpu cycles are wasted pointlessly.
>> 136
>> 137 The state in the mds sysfs file reflects this situation accordingly.
>> 138
131 139
132 Mitigation mechanism 140 Mitigation mechanism
133 ------------------------- 141 -------------------------
134 142
135 The kernel detects the affected CPUs and the p 143 The kernel detects the affected CPUs and the presence of the microcode
136 which is required. 144 which is required.
137 145
138 If a CPU is affected and the microcode is avai 146 If a CPU is affected and the microcode is available, then the kernel
139 enables the mitigation by default. The mitigat 147 enables the mitigation by default. The mitigation can be controlled at boot
140 time via a kernel command line option. See 148 time via a kernel command line option. See
141 :ref:`mds_mitigation_control_command_line`. 149 :ref:`mds_mitigation_control_command_line`.
142 150
143 .. _cpu_buffer_clear: 151 .. _cpu_buffer_clear:
144 152
145 CPU buffer clearing 153 CPU buffer clearing
146 ^^^^^^^^^^^^^^^^^^^ 154 ^^^^^^^^^^^^^^^^^^^
147 155
148 The mitigation for MDS clears the affected C 156 The mitigation for MDS clears the affected CPU buffers on return to user
149 space and when entering a guest. 157 space and when entering a guest.
150 158
151 If SMT is enabled it also clears the buffers 159 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 160 is only affected by MSBDS and not any other MDS variant, because the
153 other variants cannot be protected against c 161 other variants cannot be protected against cross Hyper-Thread attacks.
154 162
155 For CPUs which are only affected by MSBDS th 163 For CPUs which are only affected by MSBDS the user space, guest and idle
156 transition mitigations are sufficient and SM 164 transition mitigations are sufficient and SMT is not affected.
157 165
158 .. _virt_mechanism: 166 .. _virt_mechanism:
159 167
160 Virtualization mitigation 168 Virtualization mitigation
161 ^^^^^^^^^^^^^^^^^^^^^^^^^ 169 ^^^^^^^^^^^^^^^^^^^^^^^^^
162 170
163 The protection for host to guest transition 171 The protection for host to guest transition depends on the L1TF
164 vulnerability of the CPU: 172 vulnerability of the CPU:
165 173
166 - CPU is affected by L1TF: 174 - CPU is affected by L1TF:
167 175
168 If the L1D flush mitigation is enabled and 176 If the L1D flush mitigation is enabled and up to date microcode is
169 available, the L1D flush mitigation is aut 177 available, the L1D flush mitigation is automatically protecting the
170 guest transition. 178 guest transition.
171 179
172 If the L1D flush mitigation is disabled th 180 If the L1D flush mitigation is disabled then the MDS mitigation is
173 invoked explicit when the host MDS mitigat 181 invoked explicit when the host MDS mitigation is enabled.
174 182
175 For details on L1TF and virtualization see 183 For details on L1TF and virtualization see:
176 :ref:`Documentation/admin-guide/hw-vuln//l 184 :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <mitigation_control_kvm>`.
177 185
178 - CPU is not affected by L1TF: 186 - CPU is not affected by L1TF:
179 187
180 CPU buffers are flushed before entering th 188 CPU buffers are flushed before entering the guest when the host MDS
181 mitigation is enabled. 189 mitigation is enabled.
182 190
183 The resulting MDS protection matrix for the 191 The resulting MDS protection matrix for the host to guest transition:
184 192
185 ============ ===== ============= =========== 193 ============ ===== ============= ============ =================
186 L1TF MDS VMX-L1FLUSH Host MDS 194 L1TF MDS VMX-L1FLUSH Host MDS MDS-State
187 195
188 Don't care No Don't care N/A 196 Don't care No Don't care N/A Not affected
189 197
190 Yes Yes Disabled Off 198 Yes Yes Disabled Off Vulnerable
191 199
192 Yes Yes Disabled Full 200 Yes Yes Disabled Full Mitigated
193 201
194 Yes Yes Enabled Don't care 202 Yes Yes Enabled Don't care Mitigated
195 203
196 No Yes N/A Off 204 No Yes N/A Off Vulnerable
197 205
198 No Yes N/A Full 206 No Yes N/A Full Mitigated
199 ============ ===== ============= =========== 207 ============ ===== ============= ============ =================
200 208
201 This only covers the host to guest transitio 209 This only covers the host to guest transition, i.e. prevents leakage from
202 host to guest, but does not protect the gues 210 host to guest, but does not protect the guest internally. Guests need to
203 have their own protections. 211 have their own protections.
204 212
205 .. _xeon_phi: 213 .. _xeon_phi:
206 214
207 XEON PHI specific considerations 215 XEON PHI specific considerations
208 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 216 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
209 217
210 The XEON PHI processor family is affected by 218 The XEON PHI processor family is affected by MSBDS which can be exploited
211 cross Hyper-Threads when entering idle state 219 cross Hyper-Threads when entering idle states. Some XEON PHI variants allow
212 to use MWAIT in user space (Ring 3) which op 220 to use MWAIT in user space (Ring 3) which opens an potential attack vector
213 for malicious user space. The exposure can b 221 for malicious user space. The exposure can be disabled on the kernel
214 command line with the 'ring3mwait=disable' c 222 command line with the 'ring3mwait=disable' command line option.
215 223
216 XEON PHI is not affected by the other MDS va 224 XEON PHI is not affected by the other MDS variants and MSBDS is mitigated
217 before the CPU enters a idle state. As XEON 225 before the CPU enters a idle state. As XEON PHI is not affected by L1TF
218 either disabling SMT is not required for ful 226 either disabling SMT is not required for full protection.
219 227
220 .. _mds_smt_control: 228 .. _mds_smt_control:
221 229
222 SMT control 230 SMT control
223 ^^^^^^^^^^^ 231 ^^^^^^^^^^^
224 232
225 All MDS variants except MSBDS can be attacke 233 All MDS variants except MSBDS can be attacked cross Hyper-Threads. That
226 means on CPUs which are affected by MFBDS or 234 means on CPUs which are affected by MFBDS or MLPDS it is necessary to
227 disable SMT for full protection. These are m 235 disable SMT for full protection. These are most of the affected CPUs; the
228 exception is XEON PHI, see :ref:`xeon_phi`. 236 exception is XEON PHI, see :ref:`xeon_phi`.
229 237
230 Disabling SMT can have a significant perform 238 Disabling SMT can have a significant performance impact, but the impact
231 depends on the type of workloads. 239 depends on the type of workloads.
232 240
233 See the relevant chapter in the L1TF mitigat 241 See the relevant chapter in the L1TF mitigation documentation for details:
234 :ref:`Documentation/admin-guide/hw-vuln/l1tf 242 :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst <smt_control>`.
235 243
236 244
237 .. _mds_mitigation_control_command_line: 245 .. _mds_mitigation_control_command_line:
238 246
239 Mitigation control on the kernel command line 247 Mitigation control on the kernel command line
240 --------------------------------------------- 248 ---------------------------------------------
241 249
242 The kernel command line allows to control the 250 The kernel command line allows to control the MDS mitigations at boot
243 time with the option "mds=". The valid argumen 251 time with the option "mds=". The valid arguments for this option are:
244 252
245 ============ ============================== 253 ============ =============================================================
246 full If the CPU is vulnerable, enab 254 full If the CPU is vulnerable, enable all available mitigations
247 for the MDS vulnerability, CPU 255 for the MDS vulnerability, CPU buffer clearing on exit to
248 userspace and when entering a 256 userspace and when entering a VM. Idle transitions are
249 protected as well if SMT is en 257 protected as well if SMT is enabled.
250 258
251 It does not automatically disa 259 It does not automatically disable SMT.
252 260
253 full,nosmt The same as mds=full, with SMT 261 full,nosmt The same as mds=full, with SMT disabled on vulnerable
254 CPUs. This is the complete mi 262 CPUs. This is the complete mitigation.
255 263
256 off Disables MDS mitigations compl 264 off Disables MDS mitigations completely.
257 265
258 ============ ============================== 266 ============ =============================================================
259 267
260 Not specifying this option is equivalent to "m 268 Not specifying this option is equivalent to "mds=full". For processors
261 that are affected by both TAA (TSX Asynchronou 269 that are affected by both TAA (TSX Asynchronous Abort) and MDS,
262 specifying just "mds=off" without an accompany 270 specifying just "mds=off" without an accompanying "tsx_async_abort=off"
263 will have no effect as the same mitigation is 271 will have no effect as the same mitigation is used for both
264 vulnerabilities. 272 vulnerabilities.
265 273
266 Mitigation selection guide 274 Mitigation selection guide
267 -------------------------- 275 --------------------------
268 276
269 1. Trusted userspace 277 1. Trusted userspace
270 ^^^^^^^^^^^^^^^^^^^^ 278 ^^^^^^^^^^^^^^^^^^^^
271 279
272 If all userspace applications are from a tr 280 If all userspace applications are from a trusted source and do not
273 execute untrusted code which is supplied ex 281 execute untrusted code which is supplied externally, then the mitigation
274 can be disabled. 282 can be disabled.
275 283
276 284
277 2. Virtualization with trusted guests 285 2. Virtualization with trusted guests
278 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 286 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
279 287
280 The same considerations as above versus tru 288 The same considerations as above versus trusted user space apply.
281 289
282 3. Virtualization with untrusted guests 290 3. Virtualization with untrusted guests
283 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 291 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
284 292
285 The protection depends on the state of the 293 The protection depends on the state of the L1TF mitigations.
286 See :ref:`virt_mechanism`. 294 See :ref:`virt_mechanism`.
287 295
288 If the MDS mitigation is enabled and SMT is 296 If the MDS mitigation is enabled and SMT is disabled, guest to host and
289 guest to guest attacks are prevented. 297 guest to guest attacks are prevented.
290 298
291 .. _mds_default_mitigations: 299 .. _mds_default_mitigations:
292 300
293 Default mitigations 301 Default mitigations
294 ------------------- 302 -------------------
295 303
296 The kernel default mitigations for vulnerabl 304 The kernel default mitigations for vulnerable processors are:
297 305
298 - Enable CPU buffer clearing 306 - Enable CPU buffer clearing
299 307
300 The kernel does not by default enforce the d 308 The kernel does not by default enforce the disabling of SMT, which leaves
301 SMT systems vulnerable when running untruste 309 SMT systems vulnerable when running untrusted code. The same rationale as
302 for L1TF applies. 310 for L1TF applies.
303 See :ref:`Documentation/admin-guide/hw-vuln/ 311 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.