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/x86/mds.rst <mds>`.
62
63
64Attack scenarios
65----------------
66
67Attacks against the MDS vulnerabilities can be mounted from malicious non
68priviledged 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.
106
107         The mitigation is enabled on a best effort basis. See :ref:`vmwerv`
108     * - 'Mitigation: Clear CPU buffers'
109       - The processor is vulnerable and the CPU buffer clearing mitigation is
110         enabled.
111
112If the processor is vulnerable then the following information is appended
113to the above information:
114
115    ========================  ============================================
116    'SMT vulnerable'          SMT is enabled
117    'SMT mitigated'           SMT is enabled and mitigated
118    'SMT disabled'            SMT is disabled
119    'SMT Host state unknown'  Kernel runs in a VM, Host SMT state unknown
120    ========================  ============================================
121
122.. _vmwerv:
123
124Best 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
139
140Mitigation mechanism
141-------------------------
142
143The kernel detects the affected CPUs and the presence of the microcode
144which is required.
145
146If a CPU is affected and the microcode is available, then the kernel
147enables the mitigation by default. The mitigation can be controlled at boot
148time via a kernel command line option. See
149:ref:`mds_mitigation_control_command_line`.
150
151.. _cpu_buffer_clear:
152
153CPU buffer clearing
154^^^^^^^^^^^^^^^^^^^
155
156  The mitigation for MDS clears the affected CPU buffers on return to user
157  space and when entering a guest.
158
159  If SMT is enabled it also clears the buffers on idle entry when the CPU
160  is only affected by MSBDS and not any other MDS variant, because the
161  other variants cannot be protected against cross Hyper-Thread attacks.
162
163  For CPUs which are only affected by MSBDS the user space, guest and idle
164  transition mitigations are sufficient and SMT is not affected.
165
166.. _virt_mechanism:
167
168Virtualization mitigation
169^^^^^^^^^^^^^^^^^^^^^^^^^
170
171  The protection for host to guest transition depends on the L1TF
172  vulnerability of the CPU:
173
174  - CPU is affected by L1TF:
175
176    If the L1D flush mitigation is enabled and up to date microcode is
177    available, the L1D flush mitigation is automatically protecting the
178    guest transition.
179
180    If the L1D flush mitigation is disabled then the MDS mitigation is
181    invoked explicit when the host MDS mitigation is enabled.
182
183    For details on L1TF and virtualization see:
184    :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <mitigation_control_kvm>`.
185
186  - CPU is not affected by L1TF:
187
188    CPU buffers are flushed before entering the guest when the host MDS
189    mitigation is enabled.
190
191  The resulting MDS protection matrix for the host to guest transition:
192
193  ============ ===== ============= ============ =================
194   L1TF         MDS   VMX-L1FLUSH   Host MDS     MDS-State
195
196   Don't care   No    Don't care    N/A          Not affected
197
198   Yes          Yes   Disabled      Off          Vulnerable
199
200   Yes          Yes   Disabled      Full         Mitigated
201
202   Yes          Yes   Enabled       Don't care   Mitigated
203
204   No           Yes   N/A           Off          Vulnerable
205
206   No           Yes   N/A           Full         Mitigated
207  ============ ===== ============= ============ =================
208
209  This only covers the host to guest transition, i.e. prevents leakage from
210  host to guest, but does not protect the guest internally. Guests need to
211  have their own protections.
212
213.. _xeon_phi:
214
215XEON PHI specific considerations
216^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
217
218  The XEON PHI processor family is affected by MSBDS which can be exploited
219  cross Hyper-Threads when entering idle states. Some XEON PHI variants allow
220  to use MWAIT in user space (Ring 3) which opens an potential attack vector
221  for malicious user space. The exposure can be disabled on the kernel
222  command line with the 'ring3mwait=disable' command line option.
223
224  XEON PHI is not affected by the other MDS variants and MSBDS is mitigated
225  before the CPU enters a idle state. As XEON PHI is not affected by L1TF
226  either disabling SMT is not required for full protection.
227
228.. _mds_smt_control:
229
230SMT control
231^^^^^^^^^^^
232
233  All MDS variants except MSBDS can be attacked cross Hyper-Threads. That
234  means on CPUs which are affected by MFBDS or MLPDS it is necessary to
235  disable SMT for full protection. These are most of the affected CPUs; the
236  exception is XEON PHI, see :ref:`xeon_phi`.
237
238  Disabling SMT can have a significant performance impact, but the impact
239  depends on the type of workloads.
240
241  See the relevant chapter in the L1TF mitigation documentation for details:
242  :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst <smt_control>`.
243
244
245.. _mds_mitigation_control_command_line:
246
247Mitigation control on the kernel command line
248---------------------------------------------
249
250The kernel command line allows to control the MDS mitigations at boot
251time with the option "mds=". The valid arguments for this option are:
252
253  ============  =============================================================
254  full		If the CPU is vulnerable, enable all available mitigations
255		for the MDS vulnerability, CPU buffer clearing on exit to
256		userspace and when entering a VM. Idle transitions are
257		protected as well if SMT is enabled.
258
259		It does not automatically disable SMT.
260
261  full,nosmt	The same as mds=full, with SMT disabled on vulnerable
262		CPUs.  This is the complete mitigation.
263
264  off		Disables MDS mitigations completely.
265
266  ============  =============================================================
267
268Not specifying this option is equivalent to "mds=full".
269
270
271Mitigation selection guide
272--------------------------
273
2741. Trusted userspace
275^^^^^^^^^^^^^^^^^^^^
276
277   If all userspace applications are from a trusted source and do not
278   execute untrusted code which is supplied externally, then the mitigation
279   can be disabled.
280
281
2822. Virtualization with trusted guests
283^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
284
285   The same considerations as above versus trusted user space apply.
286
2873. Virtualization with untrusted guests
288^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
289
290   The protection depends on the state of the L1TF mitigations.
291   See :ref:`virt_mechanism`.
292
293   If the MDS mitigation is enabled and SMT is disabled, guest to host and
294   guest to guest attacks are prevented.
295
296.. _mds_default_mitigations:
297
298Default mitigations
299-------------------
300
301  The kernel default mitigations for vulnerable processors are:
302
303  - Enable CPU buffer clearing
304
305  The kernel does not by default enforce the disabling of SMT, which leaves
306  SMT systems vulnerable when running untrusted code. The same rationale as
307  for L1TF applies.
308  See :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <default_mitigations>`.
309