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