1 .. SPDX-License-Identifier: GPL-2.0 1 .. SPDX-License-Identifier: GPL-2.0
2 2
3 Spectre Side Channels 3 Spectre Side Channels
4 ===================== 4 =====================
5 5
6 Spectre is a class of side channel attacks tha 6 Spectre is a class of side channel attacks that exploit branch prediction
7 and speculative execution on modern CPUs to re 7 and speculative execution on modern CPUs to read memory, possibly
8 bypassing access controls. Speculative executi 8 bypassing access controls. Speculative execution side channel exploits
9 do not modify memory but attempt to infer priv 9 do not modify memory but attempt to infer privileged data in the memory.
10 10
11 This document covers Spectre variant 1 and Spe 11 This document covers Spectre variant 1 and Spectre variant 2.
12 12
13 Affected processors 13 Affected processors
14 ------------------- 14 -------------------
15 15
16 Speculative execution side channel methods aff 16 Speculative execution side channel methods affect a wide range of modern
17 high performance processors, since most modern 17 high performance processors, since most modern high speed processors
18 use branch prediction and speculative executio 18 use branch prediction and speculative execution.
19 19
20 The following CPUs are vulnerable: 20 The following CPUs are vulnerable:
21 21
22 - Intel Core, Atom, Pentium, and Xeon proc 22 - Intel Core, Atom, Pentium, and Xeon processors
23 23
24 - AMD Phenom, EPYC, and Zen processors 24 - AMD Phenom, EPYC, and Zen processors
25 25
26 - IBM POWER and zSeries processors 26 - IBM POWER and zSeries processors
27 27
28 - Higher end ARM processors 28 - Higher end ARM processors
29 29
30 - Apple CPUs 30 - Apple CPUs
31 31
32 - Higher end MIPS CPUs 32 - Higher end MIPS CPUs
33 33
34 - Likely most other high performance CPUs. 34 - Likely most other high performance CPUs. Contact your CPU vendor for details.
35 35
36 Whether a processor is affected or not can be 36 Whether a processor is affected or not can be read out from the Spectre
37 vulnerability files in sysfs. See :ref:`spectr 37 vulnerability files in sysfs. See :ref:`spectre_sys_info`.
38 38
39 Related CVEs 39 Related CVEs
40 ------------ 40 ------------
41 41
42 The following CVE entries describe Spectre var 42 The following CVE entries describe Spectre variants:
43 43
44 ============= ======================= == 44 ============= ======================= ==========================
45 CVE-2017-5753 Bounds check bypass Sp 45 CVE-2017-5753 Bounds check bypass Spectre variant 1
46 CVE-2017-5715 Branch target injection Sp 46 CVE-2017-5715 Branch target injection Spectre variant 2
47 CVE-2019-1125 Spectre v1 swapgs Sp 47 CVE-2019-1125 Spectre v1 swapgs Spectre variant 1 (swapgs)
48 ============= ======================= == 48 ============= ======================= ==========================
49 49
50 Problem 50 Problem
51 ------- 51 -------
52 52
53 CPUs use speculative operations to improve per 53 CPUs use speculative operations to improve performance. That may leave
54 traces of memory accesses or computations in t 54 traces of memory accesses or computations in the processor's caches,
55 buffers, and branch predictors. Malicious soft 55 buffers, and branch predictors. Malicious software may be able to
56 influence the speculative execution paths, and 56 influence the speculative execution paths, and then use the side effects
57 of the speculative execution in the CPUs' cach 57 of the speculative execution in the CPUs' caches and buffers to infer
58 privileged data touched during the speculative 58 privileged data touched during the speculative execution.
59 59
60 Spectre variant 1 attacks take advantage of sp 60 Spectre variant 1 attacks take advantage of speculative execution of
61 conditional branches, while Spectre variant 2 61 conditional branches, while Spectre variant 2 attacks use speculative
62 execution of indirect branches to leak privile 62 execution of indirect branches to leak privileged memory.
63 See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref 63 See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[6] <spec_ref6>`
64 :ref:`[7] <spec_ref7>` :ref:`[10] <spec_ref10> 64 :ref:`[7] <spec_ref7>` :ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.
65 65
66 Spectre variant 1 (Bounds Check Bypass) 66 Spectre variant 1 (Bounds Check Bypass)
67 --------------------------------------- 67 ---------------------------------------
68 68
69 The bounds check bypass attack :ref:`[2] <spec 69 The bounds check bypass attack :ref:`[2] <spec_ref2>` takes advantage
70 of speculative execution that bypasses conditi 70 of speculative execution that bypasses conditional branch instructions
71 used for memory access bounds check (e.g. chec 71 used for memory access bounds check (e.g. checking if the index of an
72 array results in memory access within a valid 72 array results in memory access within a valid range). This results in
73 memory accesses to invalid memory (with out-of 73 memory accesses to invalid memory (with out-of-bound index) that are
74 done speculatively before validation checks re 74 done speculatively before validation checks resolve. Such speculative
75 memory accesses can leave side effects, creati 75 memory accesses can leave side effects, creating side channels which
76 leak information to the attacker. 76 leak information to the attacker.
77 77
78 There are some extensions of Spectre variant 1 78 There are some extensions of Spectre variant 1 attacks for reading data
79 over the network, see :ref:`[12] <spec_ref12>` 79 over the network, see :ref:`[12] <spec_ref12>`. However such attacks
80 are difficult, low bandwidth, fragile, and are 80 are difficult, low bandwidth, fragile, and are considered low risk.
81 81
82 Note that, despite "Bounds Check Bypass" name, 82 Note that, despite "Bounds Check Bypass" name, Spectre variant 1 is not
83 only about user-controlled array bounds checks 83 only about user-controlled array bounds checks. It can affect any
84 conditional checks. The kernel entry code int 84 conditional checks. The kernel entry code interrupt, exception, and NMI
85 handlers all have conditional swapgs checks. 85 handlers all have conditional swapgs checks. Those may be problematic
86 in the context of Spectre v1, as kernel code c 86 in the context of Spectre v1, as kernel code can speculatively run with
87 a user GS. 87 a user GS.
88 88
89 Spectre variant 2 (Branch Target Injection) 89 Spectre variant 2 (Branch Target Injection)
90 ------------------------------------------- 90 -------------------------------------------
91 91
92 The branch target injection attack takes advan 92 The branch target injection attack takes advantage of speculative
93 execution of indirect branches :ref:`[3] <spec 93 execution of indirect branches :ref:`[3] <spec_ref3>`. The indirect
94 branch predictors inside the processor used to 94 branch predictors inside the processor used to guess the target of
95 indirect branches can be influenced by an atta 95 indirect branches can be influenced by an attacker, causing gadget code
96 to be speculatively executed, thus exposing se 96 to be speculatively executed, thus exposing sensitive data touched by
97 the victim. The side effects left in the CPU's 97 the victim. The side effects left in the CPU's caches during speculative
98 execution can be measured to infer data values 98 execution can be measured to infer data values.
99 99
100 .. _poison_btb: 100 .. _poison_btb:
101 101
102 In Spectre variant 2 attacks, the attacker can 102 In Spectre variant 2 attacks, the attacker can steer speculative indirect
103 branches in the victim to gadget code by poiso 103 branches in the victim to gadget code by poisoning the branch target
104 buffer of a CPU used for predicting indirect b 104 buffer of a CPU used for predicting indirect branch addresses. Such
105 poisoning could be done by indirect branching 105 poisoning could be done by indirect branching into existing code,
106 with the address offset of the indirect branch 106 with the address offset of the indirect branch under the attacker's
107 control. Since the branch prediction on impact 107 control. Since the branch prediction on impacted hardware does not
108 fully disambiguate branch address and uses the 108 fully disambiguate branch address and uses the offset for prediction,
109 this could cause privileged code's indirect br 109 this could cause privileged code's indirect branch to jump to a gadget
110 code with the same offset. 110 code with the same offset.
111 111
112 The most useful gadgets take an attacker-contr 112 The most useful gadgets take an attacker-controlled input parameter (such
113 as a register value) so that the memory read c 113 as a register value) so that the memory read can be controlled. Gadgets
114 without input parameters might be possible, bu 114 without input parameters might be possible, but the attacker would have
115 very little control over what memory can be re 115 very little control over what memory can be read, reducing the risk of
116 the attack revealing useful data. 116 the attack revealing useful data.
117 117
118 One other variant 2 attack vector is for the a 118 One other variant 2 attack vector is for the attacker to poison the
119 return stack buffer (RSB) :ref:`[13] <spec_ref 119 return stack buffer (RSB) :ref:`[13] <spec_ref13>` to cause speculative
120 subroutine return instruction execution to go 120 subroutine return instruction execution to go to a gadget. An attacker's
121 imbalanced subroutine call instructions might 121 imbalanced subroutine call instructions might "poison" entries in the
122 return stack buffer which are later consumed b 122 return stack buffer which are later consumed by a victim's subroutine
123 return instructions. This attack can be mitig 123 return instructions. This attack can be mitigated by flushing the return
124 stack buffer on context switch, or virtual mac 124 stack buffer on context switch, or virtual machine (VM) exit.
125 125
126 On systems with simultaneous multi-threading ( 126 On systems with simultaneous multi-threading (SMT), attacks are possible
127 from the sibling thread, as level 1 cache and 127 from the sibling thread, as level 1 cache and branch target buffer
128 (BTB) may be shared between hardware threads i 128 (BTB) may be shared between hardware threads in a CPU core. A malicious
129 program running on the sibling thread may infl 129 program running on the sibling thread may influence its peer's BTB to
130 steer its indirect branch speculations to gadg 130 steer its indirect branch speculations to gadget code, and measure the
131 speculative execution's side effects left in l 131 speculative execution's side effects left in level 1 cache to infer the
132 victim's data. 132 victim's data.
133 133
134 Yet another variant 2 attack vector is for the 134 Yet another variant 2 attack vector is for the attacker to poison the
135 Branch History Buffer (BHB) to speculatively s 135 Branch History Buffer (BHB) to speculatively steer an indirect branch
136 to a specific Branch Target Buffer (BTB) entry 136 to a specific Branch Target Buffer (BTB) entry, even if the entry isn't
137 associated with the source address of the indi 137 associated with the source address of the indirect branch. Specifically,
138 the BHB might be shared across privilege level 138 the BHB might be shared across privilege levels even in the presence of
139 Enhanced IBRS. 139 Enhanced IBRS.
140 140
141 Previously the only known real-world BHB attac !! 141 Currently the only known real-world BHB attack vector is via
142 eBPF. Further research has found attacks that !! 142 unprivileged eBPF. Therefore, it's highly recommended to not enable
143 For a full mitigation against BHB attacks it i !! 143 unprivileged eBPF, especially when eIBRS is used (without retpolines).
144 use the BHB clearing sequence. !! 144 For a full mitigation against BHB attacks, it's recommended to use
>> 145 retpolines (or eIBRS combined with retpolines).
145 146
146 Attack scenarios 147 Attack scenarios
147 ---------------- 148 ----------------
148 149
149 The following list of attack scenarios have be 150 The following list of attack scenarios have been anticipated, but may
150 not cover all possible attack vectors. 151 not cover all possible attack vectors.
151 152
152 1. A user process attacking the kernel 153 1. A user process attacking the kernel
153 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 154 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
154 155
155 Spectre variant 1 156 Spectre variant 1
156 ~~~~~~~~~~~~~~~~~ 157 ~~~~~~~~~~~~~~~~~
157 158
158 The attacker passes a parameter to the kern 159 The attacker passes a parameter to the kernel via a register or
159 via a known address in memory during a sysc 160 via a known address in memory during a syscall. Such parameter may
160 be used later by the kernel as an index to 161 be used later by the kernel as an index to an array or to derive
161 a pointer for a Spectre variant 1 attack. 162 a pointer for a Spectre variant 1 attack. The index or pointer
162 is invalid, but bound checks are bypassed i 163 is invalid, but bound checks are bypassed in the code branch taken
163 for speculative execution. This could cause 164 for speculative execution. This could cause privileged memory to be
164 accessed and leaked. 165 accessed and leaked.
165 166
166 For kernel code that has been identified wh 167 For kernel code that has been identified where data pointers could
167 potentially be influenced for Spectre attac 168 potentially be influenced for Spectre attacks, new "nospec" accessor
168 macros are used to prevent speculative load 169 macros are used to prevent speculative loading of data.
169 170
170 Spectre variant 1 (swapgs) 171 Spectre variant 1 (swapgs)
171 ~~~~~~~~~~~~~~~~~~~~~~~~~~ 172 ~~~~~~~~~~~~~~~~~~~~~~~~~~
172 173
173 An attacker can train the branch predictor 174 An attacker can train the branch predictor to speculatively skip the
174 swapgs path for an interrupt or exception. 175 swapgs path for an interrupt or exception. If they initialize
175 the GS register to a user-space value, if t 176 the GS register to a user-space value, if the swapgs is speculatively
176 skipped, subsequent GS-related percpu acces 177 skipped, subsequent GS-related percpu accesses in the speculation
177 window will be done with the attacker-contr 178 window will be done with the attacker-controlled GS value. This
178 could cause privileged memory to be accesse 179 could cause privileged memory to be accessed and leaked.
179 180
180 For example: 181 For example:
181 182
182 :: 183 ::
183 184
184 if (coming from user space) 185 if (coming from user space)
185 swapgs 186 swapgs
186 mov %gs:<percpu_offset>, %reg 187 mov %gs:<percpu_offset>, %reg
187 mov (%reg), %reg1 188 mov (%reg), %reg1
188 189
189 When coming from user space, the CPU can sp 190 When coming from user space, the CPU can speculatively skip the
190 swapgs, and then do a speculative percpu lo 191 swapgs, and then do a speculative percpu load using the user GS
191 value. So the user can speculatively force 192 value. So the user can speculatively force a read of any kernel
192 value. If a gadget exists which uses the p 193 value. If a gadget exists which uses the percpu value as an address
193 in another load/store, then the contents of 194 in another load/store, then the contents of the kernel value may
194 become visible via an L1 side channel attac 195 become visible via an L1 side channel attack.
195 196
196 A similar attack exists when coming from ke 197 A similar attack exists when coming from kernel space. The CPU can
197 speculatively do the swapgs, causing the us 198 speculatively do the swapgs, causing the user GS to get used for the
198 rest of the speculative window. 199 rest of the speculative window.
199 200
200 Spectre variant 2 201 Spectre variant 2
201 ~~~~~~~~~~~~~~~~~ 202 ~~~~~~~~~~~~~~~~~
202 203
203 A spectre variant 2 attacker can :ref:`pois 204 A spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch
204 target buffer (BTB) before issuing syscall 205 target buffer (BTB) before issuing syscall to launch an attack.
205 After entering the kernel, the kernel could 206 After entering the kernel, the kernel could use the poisoned branch
206 target buffer on indirect jump and jump to 207 target buffer on indirect jump and jump to gadget code in speculative
207 execution. 208 execution.
208 209
209 If an attacker tries to control the memory 210 If an attacker tries to control the memory addresses leaked during
210 speculative execution, he would also need t 211 speculative execution, he would also need to pass a parameter to the
211 gadget, either through a register or a know 212 gadget, either through a register or a known address in memory. After
212 the gadget has executed, he can measure the 213 the gadget has executed, he can measure the side effect.
213 214
214 The kernel can protect itself against consu 215 The kernel can protect itself against consuming poisoned branch
215 target buffer entries by using return tramp 216 target buffer entries by using return trampolines (also known as
216 "retpoline") :ref:`[3] <spec_ref3>` :ref:`[ 217 "retpoline") :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` for all
217 indirect branches. Return trampolines trap 218 indirect branches. Return trampolines trap speculative execution paths
218 to prevent jumping to gadget code during sp 219 to prevent jumping to gadget code during speculative execution.
219 x86 CPUs with Enhanced Indirect Branch Rest 220 x86 CPUs with Enhanced Indirect Branch Restricted Speculation
220 (Enhanced IBRS) available in hardware shoul 221 (Enhanced IBRS) available in hardware should use the feature to
221 mitigate Spectre variant 2 instead of retpo 222 mitigate Spectre variant 2 instead of retpoline. Enhanced IBRS is
222 more efficient than retpoline. 223 more efficient than retpoline.
223 224
224 There may be gadget code in firmware which 225 There may be gadget code in firmware which could be exploited with
225 Spectre variant 2 attack by a rogue user pr 226 Spectre variant 2 attack by a rogue user process. To mitigate such
226 attacks on x86, Indirect Branch Restricted 227 attacks on x86, Indirect Branch Restricted Speculation (IBRS) feature
227 is turned on before the kernel invokes any 228 is turned on before the kernel invokes any firmware code.
228 229
229 2. A user process attacking another user proce 230 2. A user process attacking another user process
230 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 231 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
231 232
232 A malicious user process can try to attack 233 A malicious user process can try to attack another user process,
233 either via a context switch on the same har 234 either via a context switch on the same hardware thread, or from the
234 sibling hyperthread sharing a physical proc 235 sibling hyperthread sharing a physical processor core on simultaneous
235 multi-threading (SMT) system. 236 multi-threading (SMT) system.
236 237
237 Spectre variant 1 attacks generally require 238 Spectre variant 1 attacks generally require passing parameters
238 between the processes, which needs a data p 239 between the processes, which needs a data passing relationship, such
239 as remote procedure calls (RPC). Those par 240 as remote procedure calls (RPC). Those parameters are used in gadget
240 code to derive invalid data pointers access 241 code to derive invalid data pointers accessing privileged memory in
241 the attacked process. 242 the attacked process.
242 243
243 Spectre variant 2 attacks can be launched f 244 Spectre variant 2 attacks can be launched from a rogue process by
244 :ref:`poisoning <poison_btb>` the branch ta 245 :ref:`poisoning <poison_btb>` the branch target buffer. This can
245 influence the indirect branch targets for a 246 influence the indirect branch targets for a victim process that either
246 runs later on the same hardware thread, or 247 runs later on the same hardware thread, or running concurrently on
247 a sibling hardware thread sharing the same 248 a sibling hardware thread sharing the same physical core.
248 249
249 A user process can protect itself against S 250 A user process can protect itself against Spectre variant 2 attacks
250 by using the prctl() syscall to disable ind 251 by using the prctl() syscall to disable indirect branch speculation
251 for itself. An administrator can also cord 252 for itself. An administrator can also cordon off an unsafe process
252 from polluting the branch target buffer by 253 from polluting the branch target buffer by disabling the process's
253 indirect branch speculation. This comes wit 254 indirect branch speculation. This comes with a performance cost
254 from not using indirect branch speculation 255 from not using indirect branch speculation and clearing the branch
255 target buffer. When SMT is enabled on x86, 256 target buffer. When SMT is enabled on x86, for a process that has
256 indirect branch speculation disabled, Singl 257 indirect branch speculation disabled, Single Threaded Indirect Branch
257 Predictors (STIBP) :ref:`[4] <spec_ref4>` a 258 Predictors (STIBP) :ref:`[4] <spec_ref4>` are turned on to prevent the
258 sibling thread from controlling branch targ 259 sibling thread from controlling branch target buffer. In addition,
259 the Indirect Branch Prediction Barrier (IBP 260 the Indirect Branch Prediction Barrier (IBPB) is issued to clear the
260 branch target buffer when context switching 261 branch target buffer when context switching to and from such process.
261 262
262 On x86, the return stack buffer is stuffed 263 On x86, the return stack buffer is stuffed on context switch.
263 This prevents the branch target buffer from 264 This prevents the branch target buffer from being used for branch
264 prediction when the return stack buffer und 265 prediction when the return stack buffer underflows while switching to
265 a deeper call stack. Any poisoned entries i 266 a deeper call stack. Any poisoned entries in the return stack buffer
266 left by the previous process will also be c 267 left by the previous process will also be cleared.
267 268
268 User programs should use address space rand 269 User programs should use address space randomization to make attacks
269 more difficult (Set /proc/sys/kernel/random 270 more difficult (Set /proc/sys/kernel/randomize_va_space = 1 or 2).
270 271
271 3. A virtualized guest attacking the host 272 3. A virtualized guest attacking the host
272 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 273 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
273 274
274 The attack mechanism is similar to how user 275 The attack mechanism is similar to how user processes attack the
275 kernel. The kernel is entered via hyper-ca 276 kernel. The kernel is entered via hyper-calls or other virtualization
276 exit paths. 277 exit paths.
277 278
278 For Spectre variant 1 attacks, rogue guests 279 For Spectre variant 1 attacks, rogue guests can pass parameters
279 (e.g. in registers) via hyper-calls to deri 280 (e.g. in registers) via hyper-calls to derive invalid pointers to
280 speculate into privileged memory after ente 281 speculate into privileged memory after entering the kernel. For places
281 where such kernel code has been identified, 282 where such kernel code has been identified, nospec accessor macros
282 are used to stop speculative memory access. 283 are used to stop speculative memory access.
283 284
284 For Spectre variant 2 attacks, rogue guests 285 For Spectre variant 2 attacks, rogue guests can :ref:`poison
285 <poison_btb>` the branch target buffer or r 286 <poison_btb>` the branch target buffer or return stack buffer, causing
286 the kernel to jump to gadget code in the sp 287 the kernel to jump to gadget code in the speculative execution paths.
287 288
288 To mitigate variant 2, the host kernel can 289 To mitigate variant 2, the host kernel can use return trampolines
289 for indirect branches to bypass the poisone 290 for indirect branches to bypass the poisoned branch target buffer,
290 and flushing the return stack buffer on VM 291 and flushing the return stack buffer on VM exit. This prevents rogue
291 guests from affecting indirect branching in 292 guests from affecting indirect branching in the host kernel.
292 293
293 To protect host processes from rogue guests 294 To protect host processes from rogue guests, host processes can have
294 indirect branch speculation disabled via pr 295 indirect branch speculation disabled via prctl(). The branch target
295 buffer is cleared before context switching 296 buffer is cleared before context switching to such processes.
296 297
297 4. A virtualized guest attacking other guest 298 4. A virtualized guest attacking other guest
298 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 299 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
299 300
300 A rogue guest may attack another guest to g 301 A rogue guest may attack another guest to get data accessible by the
301 other guest. 302 other guest.
302 303
303 Spectre variant 1 attacks are possible if p 304 Spectre variant 1 attacks are possible if parameters can be passed
304 between guests. This may be done via mecha 305 between guests. This may be done via mechanisms such as shared memory
305 or message passing. Such parameters could 306 or message passing. Such parameters could be used to derive data
306 pointers to privileged data in guest. The 307 pointers to privileged data in guest. The privileged data could be
307 accessed by gadget code in the victim's spe 308 accessed by gadget code in the victim's speculation paths.
308 309
309 Spectre variant 2 attacks can be launched f 310 Spectre variant 2 attacks can be launched from a rogue guest by
310 :ref:`poisoning <poison_btb>` the branch ta 311 :ref:`poisoning <poison_btb>` the branch target buffer or the return
311 stack buffer. Such poisoned entries could b 312 stack buffer. Such poisoned entries could be used to influence
312 speculation execution paths in the victim g 313 speculation execution paths in the victim guest.
313 314
314 Linux kernel mitigates attacks to other gue 315 Linux kernel mitigates attacks to other guests running in the same
315 CPU hardware thread by flushing the return 316 CPU hardware thread by flushing the return stack buffer on VM exit,
316 and clearing the branch target buffer befor 317 and clearing the branch target buffer before switching to a new guest.
317 318
318 If SMT is used, Spectre variant 2 attacks f 319 If SMT is used, Spectre variant 2 attacks from an untrusted guest
319 in the sibling hyperthread can be mitigated 320 in the sibling hyperthread can be mitigated by the administrator,
320 by turning off the unsafe guest's indirect 321 by turning off the unsafe guest's indirect branch speculation via
321 prctl(). A guest can also protect itself b 322 prctl(). A guest can also protect itself by turning on microcode
322 based mitigations (such as IBPB or STIBP on 323 based mitigations (such as IBPB or STIBP on x86) within the guest.
323 324
324 .. _spectre_sys_info: 325 .. _spectre_sys_info:
325 326
326 Spectre system information 327 Spectre system information
327 -------------------------- 328 --------------------------
328 329
329 The Linux kernel provides a sysfs interface to 330 The Linux kernel provides a sysfs interface to enumerate the current
330 mitigation status of the system for Spectre: w 331 mitigation status of the system for Spectre: whether the system is
331 vulnerable, and which mitigations are active. 332 vulnerable, and which mitigations are active.
332 333
333 The sysfs file showing Spectre variant 1 mitig 334 The sysfs file showing Spectre variant 1 mitigation status is:
334 335
335 /sys/devices/system/cpu/vulnerabilities/spe 336 /sys/devices/system/cpu/vulnerabilities/spectre_v1
336 337
337 The possible values in this file are: 338 The possible values in this file are:
338 339
339 .. list-table:: 340 .. list-table::
340 341
341 * - 'Not affected' 342 * - 'Not affected'
342 - The processor is not vulnerable. 343 - The processor is not vulnerable.
343 * - 'Vulnerable: __user pointer sanitizat 344 * - 'Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers'
344 - The swapgs protections are disabled; 345 - The swapgs protections are disabled; otherwise it has
345 protection in the kernel on a case by 346 protection in the kernel on a case by case base with explicit
346 pointer sanitation and usercopy LFENC 347 pointer sanitation and usercopy LFENCE barriers.
347 * - 'Mitigation: usercopy/swapgs barriers 348 * - 'Mitigation: usercopy/swapgs barriers and __user pointer sanitization'
348 - Protection in the kernel on a case by 349 - Protection in the kernel on a case by case base with explicit
349 pointer sanitation, usercopy LFENCE b 350 pointer sanitation, usercopy LFENCE barriers, and swapgs LFENCE
350 barriers. 351 barriers.
351 352
352 However, the protections are put in place on a 353 However, the protections are put in place on a case by case basis,
353 and there is no guarantee that all possible at 354 and there is no guarantee that all possible attack vectors for Spectre
354 variant 1 are covered. 355 variant 1 are covered.
355 356
356 The spectre_v2 kernel file reports if the kern 357 The spectre_v2 kernel file reports if the kernel has been compiled with
357 retpoline mitigation or if the CPU has hardwar 358 retpoline mitigation or if the CPU has hardware mitigation, and if the
358 CPU has support for additional process-specifi 359 CPU has support for additional process-specific mitigation.
359 360
360 This file also reports CPU features enabled by 361 This file also reports CPU features enabled by microcode to mitigate
361 attack between user processes: 362 attack between user processes:
362 363
363 1. Indirect Branch Prediction Barrier (IBPB) t 364 1. Indirect Branch Prediction Barrier (IBPB) to add additional
364 isolation between processes of different us 365 isolation between processes of different users.
365 2. Single Thread Indirect Branch Predictors (S 366 2. Single Thread Indirect Branch Predictors (STIBP) to add additional
366 isolation between CPU threads running on th 367 isolation between CPU threads running on the same core.
367 368
368 These CPU features may impact performance when 369 These CPU features may impact performance when used and can be enabled
369 per process on a case-by-case base. 370 per process on a case-by-case base.
370 371
371 The sysfs file showing Spectre variant 2 mitig 372 The sysfs file showing Spectre variant 2 mitigation status is:
372 373
373 /sys/devices/system/cpu/vulnerabilities/spe 374 /sys/devices/system/cpu/vulnerabilities/spectre_v2
374 375
375 The possible values in this file are: 376 The possible values in this file are:
376 377
377 - Kernel status: 378 - Kernel status:
378 379
379 ======================================== == 380 ======================================== =================================
380 'Not affected' Th 381 'Not affected' The processor is not vulnerable
381 'Mitigation: None' Vu 382 'Mitigation: None' Vulnerable, no mitigation
382 'Mitigation: Retpolines' Us 383 'Mitigation: Retpolines' Use Retpoline thunks
383 'Mitigation: LFENCE' Us 384 'Mitigation: LFENCE' Use LFENCE instructions
384 'Mitigation: Enhanced IBRS' Ha 385 'Mitigation: Enhanced IBRS' Hardware-focused mitigation
385 'Mitigation: Enhanced IBRS + Retpolines' Ha 386 'Mitigation: Enhanced IBRS + Retpolines' Hardware-focused + Retpolines
386 'Mitigation: Enhanced IBRS + LFENCE' Ha 387 'Mitigation: Enhanced IBRS + LFENCE' Hardware-focused + LFENCE
387 ======================================== == 388 ======================================== =================================
388 389
389 - Firmware status: Show if Indirect Branch R 390 - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is
390 used to protect against Spectre variant 2 391 used to protect against Spectre variant 2 attacks when calling firmware (x86 only).
391 392
392 ========== ================================= 393 ========== =============================================================
393 'IBRS_FW' Protection against user program a 394 'IBRS_FW' Protection against user program attacks when calling firmware
394 ========== ================================= 395 ========== =============================================================
395 396
396 - Indirect branch prediction barrier (IBPB) 397 - Indirect branch prediction barrier (IBPB) status for protection between
397 processes of different users. This feature 398 processes of different users. This feature can be controlled through
398 prctl() per process, or through kernel com 399 prctl() per process, or through kernel command line options. This is
399 an x86 only feature. For more details see 400 an x86 only feature. For more details see below.
400 401
401 =================== ====================== 402 =================== ========================================================
402 'IBPB: disabled' IBPB unused 403 'IBPB: disabled' IBPB unused
403 'IBPB: always-on' Use IBPB on all tasks 404 'IBPB: always-on' Use IBPB on all tasks
404 'IBPB: conditional' Use IBPB on SECCOMP or 405 'IBPB: conditional' Use IBPB on SECCOMP or indirect branch restricted tasks
405 =================== ====================== 406 =================== ========================================================
406 407
407 - Single threaded indirect branch prediction 408 - Single threaded indirect branch prediction (STIBP) status for protection
408 between different hyper threads. This feat 409 between different hyper threads. This feature can be controlled through
409 prctl per process, or through kernel comma 410 prctl per process, or through kernel command line options. This is x86
410 only feature. For more details see below. 411 only feature. For more details see below.
411 412
412 ==================== ====================== 413 ==================== ========================================================
413 'STIBP: disabled' STIBP unused 414 'STIBP: disabled' STIBP unused
414 'STIBP: forced' Use STIBP on all tasks 415 'STIBP: forced' Use STIBP on all tasks
415 'STIBP: conditional' Use STIBP on SECCOMP o 416 'STIBP: conditional' Use STIBP on SECCOMP or indirect branch restricted tasks
416 ==================== ====================== 417 ==================== ========================================================
417 418
418 - Return stack buffer (RSB) protection statu 419 - Return stack buffer (RSB) protection status:
419 420
420 ============= ============================ 421 ============= ===========================================
421 'RSB filling' Protection of RSB on context 422 'RSB filling' Protection of RSB on context switch enabled
422 ============= ============================ 423 ============= ===========================================
423 424
424 - EIBRS Post-barrier Return Stack Buffer (PB 425 - EIBRS Post-barrier Return Stack Buffer (PBRSB) protection status:
425 426
426 =========================== =============== 427 =========================== =======================================================
427 'PBRSB-eIBRS: SW sequence' CPU is affected 428 'PBRSB-eIBRS: SW sequence' CPU is affected and protection of RSB on VMEXIT enabled
428 'PBRSB-eIBRS: Vulnerable' CPU is vulnerab 429 'PBRSB-eIBRS: Vulnerable' CPU is vulnerable
429 'PBRSB-eIBRS: Not affected' CPU is not affe 430 'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB
430 =========================== =============== 431 =========================== =======================================================
431 432
432 - Branch History Injection (BHI) protection <<
433 <<
434 .. list-table:: <<
435 <<
436 * - BHI: Not affected <<
437 - System is not affected <<
438 * - BHI: Retpoline <<
439 - System is protected by retpoline <<
440 * - BHI: BHI_DIS_S <<
441 - System is protected by BHI_DIS_S <<
442 * - BHI: SW loop, KVM SW loop <<
443 - System is protected by software clearing <<
444 * - BHI: Vulnerable <<
445 - System is vulnerable to BHI <<
446 * - BHI: Vulnerable, KVM: SW loop <<
447 - System is vulnerable; KVM is protected by <<
448 <<
449 Full mitigation might require a microcode upda 433 Full mitigation might require a microcode update from the CPU
450 vendor. When the necessary microcode is not av 434 vendor. When the necessary microcode is not available, the kernel will
451 report vulnerability. 435 report vulnerability.
452 436
453 Turning on mitigation for Spectre variant 1 an 437 Turning on mitigation for Spectre variant 1 and Spectre variant 2
454 ---------------------------------------------- 438 -----------------------------------------------------------------
455 439
456 1. Kernel mitigation 440 1. Kernel mitigation
457 ^^^^^^^^^^^^^^^^^^^^ 441 ^^^^^^^^^^^^^^^^^^^^
458 442
459 Spectre variant 1 443 Spectre variant 1
460 ~~~~~~~~~~~~~~~~~ 444 ~~~~~~~~~~~~~~~~~
461 445
462 For the Spectre variant 1, vulnerable kerne 446 For the Spectre variant 1, vulnerable kernel code (as determined
463 by code audit or scanning tools) is annotat 447 by code audit or scanning tools) is annotated on a case by case
464 basis to use nospec accessor macros for bou 448 basis to use nospec accessor macros for bounds clipping :ref:`[2]
465 <spec_ref2>` to avoid any usable disclosure 449 <spec_ref2>` to avoid any usable disclosure gadgets. However, it may
466 not cover all attack vectors for Spectre va 450 not cover all attack vectors for Spectre variant 1.
467 451
468 Copy-from-user code has an LFENCE barrier t 452 Copy-from-user code has an LFENCE barrier to prevent the access_ok()
469 check from being mis-speculated. The barri 453 check from being mis-speculated. The barrier is done by the
470 barrier_nospec() macro. 454 barrier_nospec() macro.
471 455
472 For the swapgs variant of Spectre variant 1 456 For the swapgs variant of Spectre variant 1, LFENCE barriers are
473 added to interrupt, exception and NMI entry 457 added to interrupt, exception and NMI entry where needed. These
474 barriers are done by the FENCE_SWAPGS_KERNE 458 barriers are done by the FENCE_SWAPGS_KERNEL_ENTRY and
475 FENCE_SWAPGS_USER_ENTRY macros. 459 FENCE_SWAPGS_USER_ENTRY macros.
476 460
477 Spectre variant 2 461 Spectre variant 2
478 ~~~~~~~~~~~~~~~~~ 462 ~~~~~~~~~~~~~~~~~
479 463
480 For Spectre variant 2 mitigation, the compi 464 For Spectre variant 2 mitigation, the compiler turns indirect calls or
481 jumps in the kernel into equivalent return 465 jumps in the kernel into equivalent return trampolines (retpolines)
482 :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9 466 :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target
483 addresses. Speculative execution paths und 467 addresses. Speculative execution paths under retpolines are trapped
484 in an infinite loop to prevent any speculat 468 in an infinite loop to prevent any speculative execution jumping to
485 a gadget. 469 a gadget.
486 470
487 To turn on retpoline mitigation on a vulner 471 To turn on retpoline mitigation on a vulnerable CPU, the kernel
488 needs to be compiled with a gcc compiler th 472 needs to be compiled with a gcc compiler that supports the
489 -mindirect-branch=thunk-extern -mindirect-b 473 -mindirect-branch=thunk-extern -mindirect-branch-register options.
490 If the kernel is compiled with a Clang comp 474 If the kernel is compiled with a Clang compiler, the compiler needs
491 to support -mretpoline-external-thunk optio 475 to support -mretpoline-external-thunk option. The kernel config
492 CONFIG_MITIGATION_RETPOLINE needs to be tur !! 476 CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with
493 to run with the latest updated microcode. !! 477 the latest updated microcode.
494 478
495 On Intel Skylake-era systems the mitigation 479 On Intel Skylake-era systems the mitigation covers most, but not all,
496 cases. See :ref:`[3] <spec_ref3>` for more 480 cases. See :ref:`[3] <spec_ref3>` for more details.
497 481
498 On CPUs with hardware mitigation for Spectr 482 On CPUs with hardware mitigation for Spectre variant 2 (e.g. IBRS
499 or enhanced IBRS on x86), retpoline is auto 483 or enhanced IBRS on x86), retpoline is automatically disabled at run time.
500 484
501 Systems which support enhanced IBRS (eIBRS) 485 Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at
502 boot, by setting the IBRS bit, and they're 486 boot, by setting the IBRS bit, and they're automatically protected against
503 some Spectre v2 variant attacks. The BHB ca !! 487 Spectre v2 variant attacks, including cross-thread branch target injections
504 indirect branch predictor entry, and althou !! 488 on SMT systems (STIBP). In other words, eIBRS enables STIBP too.
505 isolated between modes when eIBRS is enable <<
506 between modes. Systems which support BHI_DI <<
507 BHI attacks. <<
508 <<
509 On Intel's enhanced IBRS systems, this incl <<
510 injections on SMT systems (STIBP). In other <<
511 STIBP, too. <<
512 489
513 AMD Automatic IBRS does not protect userspa !! 490 Legacy IBRS systems clear the IBRS bit on exit to userspace and
514 the IBRS bit on exit to userspace, therefor !! 491 therefore explicitly enable STIBP for that
515 492
516 The retpoline mitigation is turned on by de 493 The retpoline mitigation is turned on by default on vulnerable
517 CPUs. It can be forced on or off by the adm 494 CPUs. It can be forced on or off by the administrator
518 via the kernel command line and sysfs contr 495 via the kernel command line and sysfs control files. See
519 :ref:`spectre_mitigation_control_command_li 496 :ref:`spectre_mitigation_control_command_line`.
520 497
521 On x86, indirect branch restricted speculat 498 On x86, indirect branch restricted speculation is turned on by default
522 before invoking any firmware code to preven 499 before invoking any firmware code to prevent Spectre variant 2 exploits
523 using the firmware. 500 using the firmware.
524 501
525 Using kernel address space randomization (C 502 Using kernel address space randomization (CONFIG_RANDOMIZE_BASE=y
526 and CONFIG_SLAB_FREELIST_RANDOM=y in the ke 503 and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes
527 attacks on the kernel generally more diffic 504 attacks on the kernel generally more difficult.
528 505
529 2. User program mitigation 506 2. User program mitigation
530 ^^^^^^^^^^^^^^^^^^^^^^^^^^ 507 ^^^^^^^^^^^^^^^^^^^^^^^^^^
531 508
532 User programs can mitigate Spectre variant 509 User programs can mitigate Spectre variant 1 using LFENCE or "bounds
533 clipping". For more details see :ref:`[2] < 510 clipping". For more details see :ref:`[2] <spec_ref2>`.
534 511
535 For Spectre variant 2 mitigation, individua 512 For Spectre variant 2 mitigation, individual user programs
536 can be compiled with return trampolines for 513 can be compiled with return trampolines for indirect branches.
537 This protects them from consuming poisoned 514 This protects them from consuming poisoned entries in the branch
538 target buffer left by malicious software. 515 target buffer left by malicious software.
539 516
540 On legacy IBRS systems, at return to usersp 517 On legacy IBRS systems, at return to userspace, implicit STIBP is disabled
541 because the kernel clears the IBRS bit. In 518 because the kernel clears the IBRS bit. In this case, the userspace programs
542 can disable indirect branch speculation via 519 can disable indirect branch speculation via prctl() (See
543 :ref:`Documentation/userspace-api/spec_ctrl 520 :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
544 On x86, this will turn on STIBP to guard ag 521 On x86, this will turn on STIBP to guard against attacks from the
545 sibling thread when the user program is run 522 sibling thread when the user program is running, and use IBPB to
546 flush the branch target buffer when switchi 523 flush the branch target buffer when switching to/from the program.
547 524
548 Restricting indirect branch speculation on 525 Restricting indirect branch speculation on a user program will
549 also prevent the program from launching a v 526 also prevent the program from launching a variant 2 attack
550 on x86. Administrators can change that beh !! 527 on x86. All sand-boxed SECCOMP programs have indirect branch
551 command line and sysfs control files. !! 528 speculation restricted by default. Administrators can change
>> 529 that behavior via the kernel command line and sysfs control files.
552 See :ref:`spectre_mitigation_control_comman 530 See :ref:`spectre_mitigation_control_command_line`.
553 531
554 Programs that disable their indirect branch 532 Programs that disable their indirect branch speculation will have
555 more overhead and run slower. 533 more overhead and run slower.
556 534
557 User programs should use address space rand 535 User programs should use address space randomization
558 (/proc/sys/kernel/randomize_va_space = 1 or 536 (/proc/sys/kernel/randomize_va_space = 1 or 2) to make attacks more
559 difficult. 537 difficult.
560 538
561 3. VM mitigation 539 3. VM mitigation
562 ^^^^^^^^^^^^^^^^ 540 ^^^^^^^^^^^^^^^^
563 541
564 Within the kernel, Spectre variant 1 attack 542 Within the kernel, Spectre variant 1 attacks from rogue guests are
565 mitigated on a case by case basis in VM exi 543 mitigated on a case by case basis in VM exit paths. Vulnerable code
566 uses nospec accessor macros for "bounds cli 544 uses nospec accessor macros for "bounds clipping", to avoid any
567 usable disclosure gadgets. However, this m 545 usable disclosure gadgets. However, this may not cover all variant
568 1 attack vectors. 546 1 attack vectors.
569 547
570 For Spectre variant 2 attacks from rogue gu 548 For Spectre variant 2 attacks from rogue guests to the kernel, the
571 Linux kernel uses retpoline or Enhanced IBR 549 Linux kernel uses retpoline or Enhanced IBRS to prevent consumption of
572 poisoned entries in branch target buffer le 550 poisoned entries in branch target buffer left by rogue guests. It also
573 flushes the return stack buffer on every VM 551 flushes the return stack buffer on every VM exit to prevent a return
574 stack buffer underflow so poisoned branch t 552 stack buffer underflow so poisoned branch target buffer could be used,
575 or attacker guests leaving poisoned entries 553 or attacker guests leaving poisoned entries in the return stack buffer.
576 554
577 To mitigate guest-to-guest attacks in the s 555 To mitigate guest-to-guest attacks in the same CPU hardware thread,
578 the branch target buffer is sanitized by fl 556 the branch target buffer is sanitized by flushing before switching
579 to a new guest on a CPU. 557 to a new guest on a CPU.
580 558
581 The above mitigations are turned on by defa 559 The above mitigations are turned on by default on vulnerable CPUs.
582 560
583 To mitigate guest-to-guest attacks from sib 561 To mitigate guest-to-guest attacks from sibling thread when SMT is
584 in use, an untrusted guest running in the s 562 in use, an untrusted guest running in the sibling thread can have
585 its indirect branch speculation disabled by 563 its indirect branch speculation disabled by administrator via prctl().
586 564
587 The kernel also allows guests to use any mi 565 The kernel also allows guests to use any microcode based mitigation
588 they choose to use (such as IBPB or STIBP o 566 they choose to use (such as IBPB or STIBP on x86) to protect themselves.
589 567
590 .. _spectre_mitigation_control_command_line: 568 .. _spectre_mitigation_control_command_line:
591 569
592 Mitigation control on the kernel command line 570 Mitigation control on the kernel command line
593 --------------------------------------------- 571 ---------------------------------------------
594 572
595 In general the kernel selects reasonable defau !! 573 Spectre variant 2 mitigation can be disabled or force enabled at the
596 current CPU. !! 574 kernel command line.
597 <<
598 Spectre default mitigations can be disabled or <<
599 command line with the following options: <<
600 575
601 - nospectre_v1 !! 576 nospectre_v1
602 - nospectre_v2 <<
603 - spectre_v2={option} <<
604 - spectre_v2_user={option} <<
605 - spectre_bhi={option} <<
606 577
607 For more details on the available options, ref !! 578 [X86,PPC] Disable mitigations for Spectre Variant 1
>> 579 (bounds check bypass). With this option data leaks are
>> 580 possible in the system.
>> 581
>> 582 nospectre_v2
>> 583
>> 584 [X86] Disable all mitigations for the Spectre variant 2
>> 585 (indirect branch prediction) vulnerability. System may
>> 586 allow data leaks with this option, which is equivalent
>> 587 to spectre_v2=off.
>> 588
>> 589
>> 590 spectre_v2=
>> 591
>> 592 [X86] Control mitigation of Spectre variant 2
>> 593 (indirect branch speculation) vulnerability.
>> 594 The default operation protects the kernel from
>> 595 user space attacks.
>> 596
>> 597 on
>> 598 unconditionally enable, implies
>> 599 spectre_v2_user=on
>> 600 off
>> 601 unconditionally disable, implies
>> 602 spectre_v2_user=off
>> 603 auto
>> 604 kernel detects whether your CPU model is
>> 605 vulnerable
>> 606
>> 607 Selecting 'on' will, and 'auto' may, choose a
>> 608 mitigation method at run time according to the
>> 609 CPU, the available microcode, the setting of the
>> 610 CONFIG_RETPOLINE configuration option, and the
>> 611 compiler with which the kernel was built.
>> 612
>> 613 Selecting 'on' will also enable the mitigation
>> 614 against user space to user space task attacks.
>> 615
>> 616 Selecting 'off' will disable both the kernel and
>> 617 the user space protections.
>> 618
>> 619 Specific mitigations can also be selected manually:
>> 620
>> 621 retpoline auto pick between generic,lfence
>> 622 retpoline,generic Retpolines
>> 623 retpoline,lfence LFENCE; indirect branch
>> 624 retpoline,amd alias for retpoline,lfence
>> 625 eibrs enhanced IBRS
>> 626 eibrs,retpoline enhanced IBRS + Retpolines
>> 627 eibrs,lfence enhanced IBRS + LFENCE
>> 628
>> 629 Not specifying this option is equivalent to
>> 630 spectre_v2=auto.
>> 631
>> 632 For user space mitigation:
>> 633
>> 634 spectre_v2_user=
>> 635
>> 636 [X86] Control mitigation of Spectre variant 2
>> 637 (indirect branch speculation) vulnerability between
>> 638 user space tasks
>> 639
>> 640 on
>> 641 Unconditionally enable mitigations. Is
>> 642 enforced by spectre_v2=on
>> 643
>> 644 off
>> 645 Unconditionally disable mitigations. Is
>> 646 enforced by spectre_v2=off
>> 647
>> 648 prctl
>> 649 Indirect branch speculation is enabled,
>> 650 but mitigation can be enabled via prctl
>> 651 per thread. The mitigation control state
>> 652 is inherited on fork.
>> 653
>> 654 prctl,ibpb
>> 655 Like "prctl" above, but only STIBP is
>> 656 controlled per thread. IBPB is issued
>> 657 always when switching between different user
>> 658 space processes.
>> 659
>> 660 seccomp
>> 661 Same as "prctl" above, but all seccomp
>> 662 threads will enable the mitigation unless
>> 663 they explicitly opt out.
>> 664
>> 665 seccomp,ibpb
>> 666 Like "seccomp" above, but only STIBP is
>> 667 controlled per thread. IBPB is issued
>> 668 always when switching between different
>> 669 user space processes.
>> 670
>> 671 auto
>> 672 Kernel selects the mitigation depending on
>> 673 the available CPU features and vulnerability.
>> 674
>> 675 Default mitigation:
>> 676 If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"
>> 677
>> 678 Not specifying this option is equivalent to
>> 679 spectre_v2_user=auto.
>> 680
>> 681 In general the kernel by default selects
>> 682 reasonable mitigations for the current CPU. To
>> 683 disable Spectre variant 2 mitigations, boot with
>> 684 spectre_v2=off. Spectre variant 1 mitigations
>> 685 cannot be disabled.
608 686
609 Mitigation selection guide 687 Mitigation selection guide
610 -------------------------- 688 --------------------------
611 689
612 1. Trusted userspace 690 1. Trusted userspace
613 ^^^^^^^^^^^^^^^^^^^^ 691 ^^^^^^^^^^^^^^^^^^^^
614 692
615 If all userspace applications are from trus 693 If all userspace applications are from trusted sources and do not
616 execute externally supplied untrusted code, 694 execute externally supplied untrusted code, then the mitigations can
617 be disabled. 695 be disabled.
618 696
619 2. Protect sensitive programs 697 2. Protect sensitive programs
620 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 698 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
621 699
622 For security-sensitive programs that have s 700 For security-sensitive programs that have secrets (e.g. crypto
623 keys), protection against Spectre variant 2 701 keys), protection against Spectre variant 2 can be put in place by
624 disabling indirect branch speculation when 702 disabling indirect branch speculation when the program is running
625 (See :ref:`Documentation/userspace-api/spec 703 (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
626 704
627 3. Sandbox untrusted programs 705 3. Sandbox untrusted programs
628 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 706 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
629 707
630 Untrusted programs that could be a source o 708 Untrusted programs that could be a source of attacks can be cordoned
631 off by disabling their indirect branch spec 709 off by disabling their indirect branch speculation when they are run
632 (See :ref:`Documentation/userspace-api/spec 710 (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
633 This prevents untrusted programs from pollu 711 This prevents untrusted programs from polluting the branch target
634 buffer. This behavior can be changed via t !! 712 buffer. All programs running in SECCOMP sandboxes have indirect
635 and sysfs control files. See !! 713 branch speculation restricted by default. This behavior can be
>> 714 changed via the kernel command line and sysfs control files. See
636 :ref:`spectre_mitigation_control_command_li 715 :ref:`spectre_mitigation_control_command_line`.
637 716
638 3. High security mode 717 3. High security mode
639 ^^^^^^^^^^^^^^^^^^^^^ 718 ^^^^^^^^^^^^^^^^^^^^^
640 719
641 All Spectre variant 2 mitigations can be fo 720 All Spectre variant 2 mitigations can be forced on
642 at boot time for all programs (See the "on" 721 at boot time for all programs (See the "on" option in
643 :ref:`spectre_mitigation_control_command_li 722 :ref:`spectre_mitigation_control_command_line`). This will add
644 overhead as indirect branch speculations fo 723 overhead as indirect branch speculations for all programs will be
645 restricted. 724 restricted.
646 725
647 On x86, branch target buffer will be flushe 726 On x86, branch target buffer will be flushed with IBPB when switching
648 to a new program. STIBP is left on all the 727 to a new program. STIBP is left on all the time to protect programs
649 against variant 2 attacks originating from 728 against variant 2 attacks originating from programs running on
650 sibling threads. 729 sibling threads.
651 730
652 Alternatively, STIBP can be used only when 731 Alternatively, STIBP can be used only when running programs
653 whose indirect branch speculation is explic 732 whose indirect branch speculation is explicitly disabled,
654 while IBPB is still used all the time when 733 while IBPB is still used all the time when switching to a new
655 program to clear the branch target buffer ( 734 program to clear the branch target buffer (See "ibpb" option in
656 :ref:`spectre_mitigation_control_command_li 735 :ref:`spectre_mitigation_control_command_line`). This "ibpb" option
657 has less performance cost than the "on" opt 736 has less performance cost than the "on" option, which leaves STIBP
658 on all the time. 737 on all the time.
659 738
660 References on Spectre 739 References on Spectre
661 --------------------- 740 ---------------------
662 741
663 Intel white papers: 742 Intel white papers:
664 743
665 .. _spec_ref1: 744 .. _spec_ref1:
666 745
667 [1] `Intel analysis of speculative execution s 746 [1] `Intel analysis of speculative execution side channels <https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf>`_.
668 747
669 .. _spec_ref2: 748 .. _spec_ref2:
670 749
671 [2] `Bounds check bypass <https://software.int 750 [2] `Bounds check bypass <https://software.intel.com/security-software-guidance/software-guidance/bounds-check-bypass>`_.
672 751
673 .. _spec_ref3: 752 .. _spec_ref3:
674 753
675 [3] `Deep dive: Retpoline: A branch target inj 754 [3] `Deep dive: Retpoline: A branch target injection mitigation <https://software.intel.com/security-software-guidance/insights/deep-dive-retpoline-branch-target-injection-mitigation>`_.
676 755
677 .. _spec_ref4: 756 .. _spec_ref4:
678 757
679 [4] `Deep Dive: Single Thread Indirect Branch 758 [4] `Deep Dive: Single Thread Indirect Branch Predictors <https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors>`_.
680 759
681 AMD white papers: 760 AMD white papers:
682 761
683 .. _spec_ref5: 762 .. _spec_ref5:
684 763
685 [5] `AMD64 technology indirect branch control 764 [5] `AMD64 technology indirect branch control extension <https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf>`_.
686 765
687 .. _spec_ref6: 766 .. _spec_ref6:
688 767
689 [6] `Software techniques for managing speculat 768 [6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf>`_.
690 769
691 ARM white papers: 770 ARM white papers:
692 771
693 .. _spec_ref7: 772 .. _spec_ref7:
694 773
695 [7] `Cache speculation side-channels <https:// 774 [7] `Cache speculation side-channels <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/download-the-whitepaper>`_.
696 775
697 .. _spec_ref8: 776 .. _spec_ref8:
698 777
699 [8] `Cache speculation issues update <https:// 778 [8] `Cache speculation issues update <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/latest-updates/cache-speculation-issues-update>`_.
700 779
701 Google white paper: 780 Google white paper:
702 781
703 .. _spec_ref9: 782 .. _spec_ref9:
704 783
705 [9] `Retpoline: a software construct for preve 784 [9] `Retpoline: a software construct for preventing branch-target-injection <https://support.google.com/faqs/answer/7625886>`_.
706 785
707 MIPS white paper: 786 MIPS white paper:
708 787
709 .. _spec_ref10: 788 .. _spec_ref10:
710 789
711 [10] `MIPS: response on speculative execution 790 [10] `MIPS: response on speculative execution and side channel vulnerabilities <https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/>`_.
712 791
713 Academic papers: 792 Academic papers:
714 793
715 .. _spec_ref11: 794 .. _spec_ref11:
716 795
717 [11] `Spectre Attacks: Exploiting Speculative 796 [11] `Spectre Attacks: Exploiting Speculative Execution <https://spectreattack.com/spectre.pdf>`_.
718 797
719 .. _spec_ref12: 798 .. _spec_ref12:
720 799
721 [12] `NetSpectre: Read Arbitrary Memory over N 800 [12] `NetSpectre: Read Arbitrary Memory over Network <https://arxiv.org/abs/1807.10535>`_.
722 801
723 .. _spec_ref13: 802 .. _spec_ref13:
724 803
725 [13] `Spectre Returns! Speculation Attacks usi 804 [13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://www.usenix.org/system/files/conference/woot18/woot18-paper-koruyeh.pdf>`_.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.