]>
Commit | Line | Data |
---|---|---|
40318558 TG |
1 | MDS - Microarchitectural Data Sampling |
2 | ====================================== | |
3 | ||
4 | Microarchitectural Data Sampling is a hardware vulnerability which allows | |
5 | unprivileged speculative access to data which is available in various CPU | |
6 | internal buffers. | |
7 | ||
8 | Affected processors | |
9 | ------------------- | |
10 | ||
11 | This vulnerability affects a wide range of Intel processors. The | |
12 | vulnerability 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 | ||
23 | Whether a processor is affected or not can be read out from the MDS | |
24 | vulnerability file in sysfs. See :ref:`mds_sys_info`. | |
25 | ||
26 | Not all processors are affected by all variants of MDS, but the mitigation | |
27 | is identical for all of them so the kernel treats them as a single | |
28 | vulnerability. | |
29 | ||
30 | Related CVEs | |
31 | ------------ | |
32 | ||
33 | The following CVE entries are related to the MDS vulnerability: | |
34 | ||
445b98a1 | 35 | ============== ===== =================================================== |
40318558 TG |
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 | |
445b98a1 PG |
39 | CVE-2019-11091 MDSUM Microarchitectural Data Sampling Uncacheable Memory |
40 | ============== ===== =================================================== | |
40318558 TG |
41 | |
42 | Problem | |
43 | ------- | |
44 | ||
45 | When performing store, load, L1 refill operations, processors write data | |
46 | into temporary microarchitectural structures (buffers). The data in the | |
47 | buffer can be forwarded to load operations as an optimization. | |
48 | ||
49 | Under certain conditions, usually a fault/assist caused by a load | |
50 | operation, data unrelated to the load memory address can be speculatively | |
51 | forwarded from the buffers. Because the load operation causes a fault or | |
52 | assist and its result will be discarded, the forwarded data will not cause | |
53 | incorrect program execution or state changes. But a malicious operation | |
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 side channel attack. | |
56 | ||
57 | Because the buffers are potentially shared between Hyper-Threads cross | |
58 | Hyper-Thread attacks are possible. | |
59 | ||
60 | Deeper technical information is available in the MDS specific x86 | |
61 | architecture section: :ref:`Documentation/x86/mds.rst <mds>`. | |
62 | ||
63 | ||
64 | Attack scenarios | |
65 | ---------------- | |
66 | ||
67 | Attacks against the MDS vulnerabilities can be mounted from malicious non | |
68 | priviledged user space applications running on hosts or guest. Malicious | |
69 | guest OSes can obviously mount attacks as well. | |
70 | ||
71 | Contrary to other speculation based vulnerabilities the MDS vulnerability | |
72 | does not allow the attacker to control the memory target address. As a | |
73 | consequence the attacks are purely sampling based, but as demonstrated with | |
74 | the TLBleed attack samples can be postprocessed successfully. | |
75 | ||
76 | Web-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 | ||
87 | MDS system information | |
88 | ----------------------- | |
89 | ||
90 | The Linux kernel provides a sysfs interface to enumerate the current MDS | |
91 | status of the system: whether the system is vulnerable, and which | |
92 | mitigations are active. The relevant sysfs file is: | |
93 | ||
94 | /sys/devices/system/cpu/vulnerabilities/mds | |
95 | ||
96 | The possible values in this file are: | |
97 | ||
98 | ========================================= ================================= | |
99 | 'Not affected' The processor is not vulnerable | |
100 | ||
101 | 'Vulnerable' The processor is vulnerable, | |
102 | but no mitigation enabled | |
103 | ||
104 | 'Vulnerable: Clear CPU buffers attempted' The processor is vulnerable but | |
105 | microcode is not updated. | |
106 | The mitigation is enabled on a | |
107 | best effort basis. | |
108 | See :ref:`vmwerv` | |
109 | ||
110 | 'Mitigation: CPU buffer clear' The processor is vulnerable and the | |
111 | CPU buffer clearing mitigation is | |
112 | enabled. | |
113 | ========================================= ================================= | |
114 | ||
115 | If the processor is vulnerable then the following information is appended | |
116 | to the above information: | |
117 | ||
118 | ======================== ============================================ | |
119 | 'SMT vulnerable' SMT is enabled | |
120 | 'SMT mitigated' SMT is enabled and mitigated | |
121 | 'SMT disabled' SMT is disabled | |
122 | 'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown | |
123 | ======================== ============================================ | |
124 | ||
125 | .. _vmwerv: | |
126 | ||
127 | Best effort mitigation mode | |
128 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
129 | ||
130 | If the processor is vulnerable, but the availability of the microcode based | |
131 | mitigation mechanism is not advertised via CPUID the kernel selects a best | |
132 | effort mitigation mode. This mode invokes the mitigation instructions | |
133 | without a guarantee that they clear the CPU buffers. | |
134 | ||
135 | This is done to address virtualization scenarios where the host has the | |
136 | microcode update applied, but the hypervisor is not yet updated to expose | |
137 | the CPUID to the guest. If the host has updated microcode the protection | |
138 | takes effect otherwise a few cpu cycles are wasted pointlessly. | |
139 | ||
140 | The state in the mds sysfs file reflects this situation accordingly. | |
141 | ||
142 | ||
143 | Mitigation mechanism | |
144 | ------------------------- | |
145 | ||
146 | The kernel detects the affected CPUs and the presence of the microcode | |
147 | which is required. | |
148 | ||
149 | If a CPU is affected and the microcode is available, then the kernel | |
150 | enables the mitigation by default. The mitigation can be controlled at boot | |
151 | time via a kernel command line option. See | |
152 | :ref:`mds_mitigation_control_command_line`. | |
153 | ||
154 | .. _cpu_buffer_clear: | |
155 | ||
156 | CPU buffer clearing | |
157 | ^^^^^^^^^^^^^^^^^^^ | |
158 | ||
159 | The mitigation for MDS clears the affected CPU buffers on return to user | |
160 | space and when entering a guest. | |
161 | ||
162 | If SMT is enabled it also clears the buffers on idle entry when the CPU | |
163 | is only affected by MSBDS and not any other MDS variant, because the | |
164 | other variants cannot be protected against cross Hyper-Thread attacks. | |
165 | ||
166 | For CPUs which are only affected by MSBDS the user space, guest and idle | |
167 | transition mitigations are sufficient and SMT is not affected. | |
168 | ||
169 | .. _virt_mechanism: | |
170 | ||
171 | Virtualization mitigation | |
172 | ^^^^^^^^^^^^^^^^^^^^^^^^^ | |
173 | ||
174 | The protection for host to guest transition depends on the L1TF | |
175 | vulnerability of the CPU: | |
176 | ||
177 | - CPU is affected by L1TF: | |
178 | ||
179 | If the L1D flush mitigation is enabled and up to date microcode is | |
180 | available, the L1D flush mitigation is automatically protecting the | |
181 | guest transition. | |
182 | ||
183 | If the L1D flush mitigation is disabled then the MDS mitigation is | |
184 | invoked explicit when the host MDS mitigation is enabled. | |
185 | ||
186 | For details on L1TF and virtualization see: | |
187 | :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <mitigation_control_kvm>`. | |
188 | ||
189 | - CPU is not affected by L1TF: | |
190 | ||
191 | CPU buffers are flushed before entering the guest when the host MDS | |
192 | mitigation is enabled. | |
193 | ||
194 | The resulting MDS protection matrix for the host to guest transition: | |
195 | ||
196 | ============ ===== ============= ============ ================= | |
197 | L1TF MDS VMX-L1FLUSH Host MDS MDS-State | |
198 | ||
199 | Don't care No Don't care N/A Not affected | |
200 | ||
201 | Yes Yes Disabled Off Vulnerable | |
202 | ||
203 | Yes Yes Disabled Full Mitigated | |
204 | ||
205 | Yes Yes Enabled Don't care Mitigated | |
206 | ||
207 | No Yes N/A Off Vulnerable | |
208 | ||
209 | No Yes N/A Full Mitigated | |
210 | ============ ===== ============= ============ ================= | |
211 | ||
212 | This only covers the host to guest transition, i.e. prevents leakage from | |
213 | host to guest, but does not protect the guest internally. Guests need to | |
214 | have their own protections. | |
215 | ||
216 | .. _xeon_phi: | |
217 | ||
218 | XEON PHI specific considerations | |
219 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
220 | ||
221 | The XEON PHI processor family is affected by MSBDS which can be exploited | |
222 | cross Hyper-Threads when entering idle states. Some XEON PHI variants allow | |
223 | to use MWAIT in user space (Ring 3) which opens an potential attack vector | |
224 | for malicious user space. The exposure can be disabled on the kernel | |
225 | command line with the 'ring3mwait=disable' command line option. | |
226 | ||
227 | XEON PHI is not affected by the other MDS variants and MSBDS is mitigated | |
228 | before the CPU enters a idle state. As XEON PHI is not affected by L1TF | |
229 | either disabling SMT is not required for full protection. | |
230 | ||
231 | .. _mds_smt_control: | |
232 | ||
233 | SMT control | |
234 | ^^^^^^^^^^^ | |
235 | ||
236 | All MDS variants except MSBDS can be attacked cross Hyper-Threads. That | |
237 | means on CPUs which are affected by MFBDS or MLPDS it is necessary to | |
238 | disable SMT for full protection. These are most of the affected CPUs; the | |
239 | exception is XEON PHI, see :ref:`xeon_phi`. | |
240 | ||
241 | Disabling SMT can have a significant performance impact, but the impact | |
242 | depends on the type of workloads. | |
243 | ||
244 | See the relevant chapter in the L1TF mitigation documentation for details: | |
245 | :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst <smt_control>`. | |
246 | ||
247 | ||
248 | .. _mds_mitigation_control_command_line: | |
249 | ||
250 | Mitigation control on the kernel command line | |
251 | --------------------------------------------- | |
252 | ||
253 | The kernel command line allows to control the MDS mitigations at boot | |
254 | time with the option "mds=". The valid arguments for this option are: | |
255 | ||
256 | ============ ============================================================= | |
257 | full If the CPU is vulnerable, enable all available mitigations | |
258 | for the MDS vulnerability, CPU buffer clearing on exit to | |
259 | userspace and when entering a VM. Idle transitions are | |
260 | protected as well if SMT is enabled. | |
261 | ||
262 | It does not automatically disable SMT. | |
263 | ||
e2f3c337 JP |
264 | full,nosmt The same as mds=full, with SMT disabled on vulnerable |
265 | CPUs. This is the complete mitigation. | |
266 | ||
40318558 TG |
267 | off Disables MDS mitigations completely. |
268 | ||
269 | ============ ============================================================= | |
270 | ||
271 | Not specifying this option is equivalent to "mds=full". | |
272 | ||
273 | ||
274 | Mitigation selection guide | |
275 | -------------------------- | |
276 | ||
277 | 1. Trusted userspace | |
278 | ^^^^^^^^^^^^^^^^^^^^ | |
279 | ||
280 | If all userspace applications are from a trusted source and do not | |
281 | execute untrusted code which is supplied externally, then the mitigation | |
282 | can be disabled. | |
283 | ||
284 | ||
285 | 2. Virtualization with trusted guests | |
286 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
287 | ||
288 | The same considerations as above versus trusted user space apply. | |
289 | ||
290 | 3. Virtualization with untrusted guests | |
291 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
292 | ||
293 | The protection depends on the state of the L1TF mitigations. | |
294 | See :ref:`virt_mechanism`. | |
295 | ||
296 | If the MDS mitigation is enabled and SMT is disabled, guest to host and | |
297 | guest to guest attacks are prevented. | |
298 | ||
299 | .. _mds_default_mitigations: | |
300 | ||
301 | Default mitigations | |
302 | ------------------- | |
303 | ||
304 | The kernel default mitigations for vulnerable processors are: | |
305 | ||
306 | - Enable CPU buffer clearing | |
307 | ||
308 | The kernel does not by default enforce the disabling of SMT, which leaves | |
309 | SMT systems vulnerable when running untrusted code. The same rationale as | |
310 | for L1TF applies. | |
311 | See :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <default_mitigations>`. |