e0dccf414ecac16d379e3546404bea2f1c1829b5
[sfrench/cifs-2.6.git] / Documentation / admin-guide / hw-vuln / mds.rst
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
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
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
264   full,nosmt    The same as mds=full, with SMT disabled on vulnerable
265                 CPUs.  This is the complete mitigation.
266
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>`.