1 Microarchitectural Data Sampling (MDS) mitigat
2 ==============================================
3
4 .. _mds:
5
6 Overview
7 --------
8
9 Microarchitectural Data Sampling (MDS) is a fa
10 on internal buffers in Intel CPUs. The variant
11
12 - Microarchitectural Store Buffer Data Sampli
13 - Microarchitectural Fill Buffer Data Samplin
14 - Microarchitectural Load Port Data Sampling
15 - Microarchitectural Data Sampling Uncacheabl
16
17 MSBDS leaks Store Buffer Entries which can be
18 dependent load (store-to-load forwarding) as a
19 can also happen to a faulting or assisting loa
20 memory address, which can be exploited under c
21 buffers are partitioned between Hyper-Threads
22 not possible. But if a thread enters or exits
23 buffer is repartitioned which can expose data
24
25 MFBDS leaks Fill Buffer Entries. Fill buffers
26 L1 miss situations and to hold data which is r
27 to a memory or I/O operation. Fill buffers can
28 operation and also write data to the cache. Wh
29 deallocated it can retain the stale data of th
30 can then be forwarded to a faulting or assisti
31 be exploited under certain conditions. Fill bu
32 Hyper-Threads so cross thread leakage is possi
33
34 MLPDS leaks Load Port Data. Load ports are use
35 from memory or I/O. The received data is then
36 file or a subsequent operation. In some implem
37 contain stale data from a previous operation w
38 faulting or assisting loads under certain cond
39 exploited eventually. Load ports are shared be
40 thread leakage is possible.
41
42 MDSUM is a special case of MSBDS, MFBDS and ML
43 memory that takes a fault or assist can leave
44 structure that may later be observed using one
45 MSBDS, MFBDS or MLPDS.
46
47 Exposure assumptions
48 --------------------
49
50 It is assumed that attack code resides in user
51 exception. The rationale behind this assumptio
52 needed for exploiting MDS requires:
53
54 - to control the load to trigger a fault or a
55
56 - to have a disclosure gadget which exposes t
57 data for consumption through a side channel
58
59 - to control the pointer through which the di
60 data
61
62 The existence of such a construct in the kerne
63 100% certainty, but the complexity involved ma
64
65 There is one exception, which is untrusted BPF
66 untrusted BPF is limited, but it needs to be t
67 whether it can be used to create such a constr
68
69
70 Mitigation strategy
71 -------------------
72
73 All variants have the same mitigation strategy
74 thread case (SMT off): Force the CPU to clear
75
76 This is achieved by using the otherwise unused
77 instruction in combination with a microcode up
78 the affected CPU buffers when the VERW instruc
79
80 For virtualization there are two ways to achie
81 clearing. Either the modified VERW instruction
82 command. The latter is issued when L1TF mitiga
83 VERW can be avoided. If the CPU is not affecte
84 be issued.
85
86 If the VERW instruction with the supplied segm
87 executed on a CPU without the microcode update
88 other than a small number of pointlessly waste
89
90 This does not protect against cross Hyper-Thre
91 which is only exploitable cross Hyper-thread w
92 enters a C-state.
93
94 The kernel provides a function to invoke the b
95
96 mds_clear_cpu_buffers()
97
98 Also macro CLEAR_CPU_BUFFERS can be used in AS
99 Other than CFLAGS.ZF, this macro doesn't clobb
100
101 The mitigation is invoked on kernel/userspace,
102 (idle) transitions.
103
104 As a special quirk to address virtualization s
105 the microcode updated, but the hypervisor does
106 MD_CLEAR CPUID bit to guests, the kernel issue
107 hope that it might actually clear the buffers.
108 accordingly.
109
110 According to current knowledge additional miti
111 itself are not required because the necessary
112 data cannot be controlled in a way which allow
113 user space or VM guests.
114
115 Kernel internal mitigation modes
116 --------------------------------
117
118 ======= =====================================
119 off Mitigation is disabled. Either the C
120 mds=off is supplied on the kernel co
121
122 full Mitigation is enabled. CPU is affect
123 advertised in CPUID.
124
125 vmwerv Mitigation is enabled. CPU is affect
126 advertised in CPUID. That is mainly
127 scenarios where the host has the upd
128 hypervisor does not expose MD_CLEAR
129 effort approach without guarantee.
130 ======= =====================================
131
132 If the CPU is affected and mds=off is not supp
133 line then the kernel selects the appropriate m
134 the availability of the MD_CLEAR CPUID bit.
135
136 Mitigation points
137 -----------------
138
139 1. Return to user space
140 ^^^^^^^^^^^^^^^^^^^^^^^
141
142 When transitioning from kernel to user spac
143 on affected CPUs when the mitigation is not
144 command line. The mitigation is enabled thr
145 X86_FEATURE_CLEAR_CPU_BUF.
146
147 The mitigation is invoked just before trans
148 user registers are restored. This is done t
149 which kernel data could be accessed after V
150 VERW.
151
152 **Corner case not handled**
153 Interrupts returning to kernel don't clear
154 exit-to-user path is expected to do that an
155 a case when an NMI is generated in kernel a
156 has cleared the buffers. This case is not h
157 kernel don't clear CPU buffers because:
158
159 1. It is rare to get an NMI after VERW, but
160 2. For an unprivileged user, there is no kn
161 less rare or target it.
162 3. It would take a large number of these pr
163 an actual attack. There's presumably no
164 4. The NMI in question occurs after a VERW,
165 restored and most interesting data is al
166 is only the data that NMI touches, and t
167 any interest.
168
169
170 2. C-State transition
171 ^^^^^^^^^^^^^^^^^^^^^
172
173 When a CPU goes idle and enters a C-State t
174 cleared on affected CPUs when SMT is active
175 repartitioning of the store buffer when one
176 a C-State.
177
178 When SMT is inactive, i.e. either the CPU d
179 sibling threads are offline CPU buffer clea
180
181 The idle clearing is enabled on CPUs which
182 and not by any other MDS variant. The other
183 protected against cross Hyper-Thread attack
184 the Load Ports are shared. So on CPUs affec
185 idle clearing would be a window dressing ex
186 activated.
187
188 The invocation is controlled by the static
189 switched depending on the chosen mitigation
190 the system.
191
192 The buffer clear is only invoked before ent
193 that stale data from the idling CPU from sp
194 sibling after the store buffer got repartit
195 available to the non idle sibling.
196
197 When coming out of idle the store buffer is
198 sibling has half of it available. The back
199 speculatively exposed to contents of the si
200 flushed either on exit to user space or on
201 in user space or the guest cannot speculati
202
203 The mitigation is hooked into all variants
204 not cover the legacy ACPI IO-Port mechanism
205 has been superseded by the intel_idle drive
206 preferred on all affected CPUs which are ex
207 functionality in microcode. Aside of that t
208 legacy interface which is only used on olde
209 not affected or do not receive microcode up
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.