1.. SPDX-License-Identifier: GPL-2.0
2
3Spectre Side Channels
4=====================
5
6Spectre is a class of side channel attacks that exploit branch prediction
7and speculative execution on modern CPUs to read memory, possibly
8bypassing access controls. Speculative execution side channel exploits
9do not modify memory but attempt to infer privileged data in the memory.
10
11This document covers Spectre variant 1 and Spectre variant 2.
12
13Affected processors
14-------------------
15
16Speculative execution side channel methods affect a wide range of modern
17high performance processors, since most modern high speed processors
18use branch prediction and speculative execution.
19
20The following CPUs are vulnerable:
21
22    - Intel Core, Atom, Pentium, and Xeon processors
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. Contact your CPU vendor for details.
35
36Whether a processor is affected or not can be read out from the Spectre
37vulnerability files in sysfs. See :ref:`spectre_sys_info`.
38
39Related CVEs
40------------
41
42The following CVE entries describe Spectre variants:
43
44   =============   =======================  ==========================
45   CVE-2017-5753   Bounds check bypass      Spectre variant 1
46   CVE-2017-5715   Branch target injection  Spectre variant 2
47   CVE-2019-1125   Spectre v1 swapgs        Spectre variant 1 (swapgs)
48   =============   =======================  ==========================
49
50Problem
51-------
52
53CPUs use speculative operations to improve performance. That may leave
54traces of memory accesses or computations in the processor's caches,
55buffers, and branch predictors. Malicious software may be able to
56influence the speculative execution paths, and then use the side effects
57of the speculative execution in the CPUs' caches and buffers to infer
58privileged data touched during the speculative execution.
59
60Spectre variant 1 attacks take advantage of speculative execution of
61conditional branches, while Spectre variant 2 attacks use speculative
62execution of indirect branches to leak privileged memory.
63See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[7] <spec_ref7>`
64:ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.
65
66Spectre variant 1 (Bounds Check Bypass)
67---------------------------------------
68
69The bounds check bypass attack :ref:`[2] <spec_ref2>` takes advantage
70of speculative execution that bypasses conditional branch instructions
71used for memory access bounds check (e.g. checking if the index of an
72array results in memory access within a valid range). This results in
73memory accesses to invalid memory (with out-of-bound index) that are
74done speculatively before validation checks resolve. Such speculative
75memory accesses can leave side effects, creating side channels which
76leak information to the attacker.
77
78There are some extensions of Spectre variant 1 attacks for reading data
79over the network, see :ref:`[12] <spec_ref12>`. However such attacks
80are difficult, low bandwidth, fragile, and are considered low risk.
81
82Note that, despite "Bounds Check Bypass" name, Spectre variant 1 is not
83only about user-controlled array bounds checks.  It can affect any
84conditional checks.  The kernel entry code interrupt, exception, and NMI
85handlers all have conditional swapgs checks.  Those may be problematic
86in the context of Spectre v1, as kernel code can speculatively run with
87a user GS.
88
89Spectre variant 2 (Branch Target Injection)
90-------------------------------------------
91
92The branch target injection attack takes advantage of speculative
93execution of indirect branches :ref:`[3] <spec_ref3>`.  The indirect
94branch predictors inside the processor used to guess the target of
95indirect branches can be influenced by an attacker, causing gadget code
96to be speculatively executed, thus exposing sensitive data touched by
97the victim. The side effects left in the CPU's caches during speculative
98execution can be measured to infer data values.
99
100.. _poison_btb:
101
102In Spectre variant 2 attacks, the attacker can steer speculative indirect
103branches in the victim to gadget code by poisoning the branch target
104buffer of a CPU used for predicting indirect branch addresses. Such
105poisoning could be done by indirect branching into existing code,
106with the address offset of the indirect branch under the attacker's
107control. Since the branch prediction on impacted hardware does not
108fully disambiguate branch address and uses the offset for prediction,
109this could cause privileged code's indirect branch to jump to a gadget
110code with the same offset.
111
112The most useful gadgets take an attacker-controlled input parameter (such
113as a register value) so that the memory read can be controlled. Gadgets
114without input parameters might be possible, but the attacker would have
115very little control over what memory can be read, reducing the risk of
116the attack revealing useful data.
117
118One other variant 2 attack vector is for the attacker to poison the
119return stack buffer (RSB) :ref:`[13] <spec_ref13>` to cause speculative
120subroutine return instruction execution to go to a gadget.  An attacker's
121imbalanced subroutine call instructions might "poison" entries in the
122return stack buffer which are later consumed by a victim's subroutine
123return instructions.  This attack can be mitigated by flushing the return
124stack buffer on context switch, or virtual machine (VM) exit.
125
126On systems with simultaneous multi-threading (SMT), attacks are possible
127from the sibling thread, as level 1 cache and branch target buffer
128(BTB) may be shared between hardware threads in a CPU core.  A malicious
129program running on the sibling thread may influence its peer's BTB to
130steer its indirect branch speculations to gadget code, and measure the
131speculative execution's side effects left in level 1 cache to infer the
132victim's data.
133
134Attack scenarios
135----------------
136
137The following list of attack scenarios have been anticipated, but may
138not cover all possible attack vectors.
139
1401. A user process attacking the kernel
141^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
142
143Spectre variant 1
144~~~~~~~~~~~~~~~~~
145
146   The attacker passes a parameter to the kernel via a register or
147   via a known address in memory during a syscall. Such parameter may
148   be used later by the kernel as an index to an array or to derive
149   a pointer for a Spectre variant 1 attack.  The index or pointer
150   is invalid, but bound checks are bypassed in the code branch taken
151   for speculative execution. This could cause privileged memory to be
152   accessed and leaked.
153
154   For kernel code that has been identified where data pointers could
155   potentially be influenced for Spectre attacks, new "nospec" accessor
156   macros are used to prevent speculative loading of data.
157
158Spectre variant 1 (swapgs)
159~~~~~~~~~~~~~~~~~~~~~~~~~~
160
161   An attacker can train the branch predictor to speculatively skip the
162   swapgs path for an interrupt or exception.  If they initialize
163   the GS register to a user-space value, if the swapgs is speculatively
164   skipped, subsequent GS-related percpu accesses in the speculation
165   window will be done with the attacker-controlled GS value.  This
166   could cause privileged memory to be accessed and leaked.
167
168   For example:
169
170   ::
171
172     if (coming from user space)
173         swapgs
174     mov %gs:<percpu_offset>, %reg
175     mov (%reg), %reg1
176
177   When coming from user space, the CPU can speculatively skip the
178   swapgs, and then do a speculative percpu load using the user GS
179   value.  So the user can speculatively force a read of any kernel
180   value.  If a gadget exists which uses the percpu value as an address
181   in another load/store, then the contents of the kernel value may
182   become visible via an L1 side channel attack.
183
184   A similar attack exists when coming from kernel space.  The CPU can
185   speculatively do the swapgs, causing the user GS to get used for the
186   rest of the speculative window.
187
188Spectre variant 2
189~~~~~~~~~~~~~~~~~
190
191   A spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch
192   target buffer (BTB) before issuing syscall to launch an attack.
193   After entering the kernel, the kernel could use the poisoned branch
194   target buffer on indirect jump and jump to gadget code in speculative
195   execution.
196
197   If an attacker tries to control the memory addresses leaked during
198   speculative execution, he would also need to pass a parameter to the
199   gadget, either through a register or a known address in memory. After
200   the gadget has executed, he can measure the side effect.
201
202   The kernel can protect itself against consuming poisoned branch
203   target buffer entries by using return trampolines (also known as
204   "retpoline") :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` for all
205   indirect branches. Return trampolines trap speculative execution paths
206   to prevent jumping to gadget code during speculative execution.
207   x86 CPUs with Enhanced Indirect Branch Restricted Speculation
208   (Enhanced IBRS) available in hardware should use the feature to
209   mitigate Spectre variant 2 instead of retpoline. Enhanced IBRS is
210   more efficient than retpoline.
211
212   There may be gadget code in firmware which could be exploited with
213   Spectre variant 2 attack by a rogue user process. To mitigate such
214   attacks on x86, Indirect Branch Restricted Speculation (IBRS) feature
215   is turned on before the kernel invokes any firmware code.
216
2172. A user process attacking another user process
218^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
219
220   A malicious user process can try to attack another user process,
221   either via a context switch on the same hardware thread, or from the
222   sibling hyperthread sharing a physical processor core on simultaneous
223   multi-threading (SMT) system.
224
225   Spectre variant 1 attacks generally require passing parameters
226   between the processes, which needs a data passing relationship, such
227   as remote procedure calls (RPC).  Those parameters are used in gadget
228   code to derive invalid data pointers accessing privileged memory in
229   the attacked process.
230
231   Spectre variant 2 attacks can be launched from a rogue process by
232   :ref:`poisoning <poison_btb>` the branch target buffer.  This can
233   influence the indirect branch targets for a victim process that either
234   runs later on the same hardware thread, or running concurrently on
235   a sibling hardware thread sharing the same physical core.
236
237   A user process can protect itself against Spectre variant 2 attacks
238   by using the prctl() syscall to disable indirect branch speculation
239   for itself.  An administrator can also cordon off an unsafe process
240   from polluting the branch target buffer by disabling the process's
241   indirect branch speculation. This comes with a performance cost
242   from not using indirect branch speculation and clearing the branch
243   target buffer.  When SMT is enabled on x86, for a process that has
244   indirect branch speculation disabled, Single Threaded Indirect Branch
245   Predictors (STIBP) :ref:`[4] <spec_ref4>` are turned on to prevent the
246   sibling thread from controlling branch target buffer.  In addition,
247   the Indirect Branch Prediction Barrier (IBPB) is issued to clear the
248   branch target buffer when context switching to and from such process.
249
250   On x86, the return stack buffer is stuffed on context switch.
251   This prevents the branch target buffer from being used for branch
252   prediction when the return stack buffer underflows while switching to
253   a deeper call stack. Any poisoned entries in the return stack buffer
254   left by the previous process will also be cleared.
255
256   User programs should use address space randomization to make attacks
257   more difficult (Set /proc/sys/kernel/randomize_va_space = 1 or 2).
258
2593. A virtualized guest attacking the host
260^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
261
262   The attack mechanism is similar to how user processes attack the
263   kernel.  The kernel is entered via hyper-calls or other virtualization
264   exit paths.
265
266   For Spectre variant 1 attacks, rogue guests can pass parameters
267   (e.g. in registers) via hyper-calls to derive invalid pointers to
268   speculate into privileged memory after entering the kernel.  For places
269   where such kernel code has been identified, nospec accessor macros
270   are used to stop speculative memory access.
271
272   For Spectre variant 2 attacks, rogue guests can :ref:`poison
273   <poison_btb>` the branch target buffer or return stack buffer, causing
274   the kernel to jump to gadget code in the speculative execution paths.
275
276   To mitigate variant 2, the host kernel can use return trampolines
277   for indirect branches to bypass the poisoned branch target buffer,
278   and flushing the return stack buffer on VM exit.  This prevents rogue
279   guests from affecting indirect branching in the host kernel.
280
281   To protect host processes from rogue guests, host processes can have
282   indirect branch speculation disabled via prctl().  The branch target
283   buffer is cleared before context switching to such processes.
284
2854. A virtualized guest attacking other guest
286^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
287
288   A rogue guest may attack another guest to get data accessible by the
289   other guest.
290
291   Spectre variant 1 attacks are possible if parameters can be passed
292   between guests.  This may be done via mechanisms such as shared memory
293   or message passing.  Such parameters could be used to derive data
294   pointers to privileged data in guest.  The privileged data could be
295   accessed by gadget code in the victim's speculation paths.
296
297   Spectre variant 2 attacks can be launched from a rogue guest by
298   :ref:`poisoning <poison_btb>` the branch target buffer or the return
299   stack buffer. Such poisoned entries could be used to influence
300   speculation execution paths in the victim guest.
301
302   Linux kernel mitigates attacks to other guests running in the same
303   CPU hardware thread by flushing the return stack buffer on VM exit,
304   and clearing the branch target buffer before switching to a new guest.
305
306   If SMT is used, Spectre variant 2 attacks from an untrusted guest
307   in the sibling hyperthread can be mitigated by the administrator,
308   by turning off the unsafe guest's indirect branch speculation via
309   prctl().  A guest can also protect itself by turning on microcode
310   based mitigations (such as IBPB or STIBP on x86) within the guest.
311
312.. _spectre_sys_info:
313
314Spectre system information
315--------------------------
316
317The Linux kernel provides a sysfs interface to enumerate the current
318mitigation status of the system for Spectre: whether the system is
319vulnerable, and which mitigations are active.
320
321The sysfs file showing Spectre variant 1 mitigation status is:
322
323   /sys/devices/system/cpu/vulnerabilities/spectre_v1
324
325The possible values in this file are:
326
327  .. list-table::
328
329     * - 'Not affected'
330       - The processor is not vulnerable.
331     * - 'Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers'
332       - The swapgs protections are disabled; otherwise it has
333         protection in the kernel on a case by case base with explicit
334         pointer sanitation and usercopy LFENCE barriers.
335     * - 'Mitigation: usercopy/swapgs barriers and __user pointer sanitization'
336       - Protection in the kernel on a case by case base with explicit
337         pointer sanitation, usercopy LFENCE barriers, and swapgs LFENCE
338         barriers.
339
340However, the protections are put in place on a case by case basis,
341and there is no guarantee that all possible attack vectors for Spectre
342variant 1 are covered.
343
344The spectre_v2 kernel file reports if the kernel has been compiled with
345retpoline mitigation or if the CPU has hardware mitigation, and if the
346CPU has support for additional process-specific mitigation.
347
348This file also reports CPU features enabled by microcode to mitigate
349attack between user processes:
350
3511. Indirect Branch Prediction Barrier (IBPB) to add additional
352   isolation between processes of different users.
3532. Single Thread Indirect Branch Predictors (STIBP) to add additional
354   isolation between CPU threads running on the same core.
355
356These CPU features may impact performance when used and can be enabled
357per process on a case-by-case base.
358
359The sysfs file showing Spectre variant 2 mitigation status is:
360
361   /sys/devices/system/cpu/vulnerabilities/spectre_v2
362
363The possible values in this file are:
364
365  - Kernel status:
366
367  ====================================  =================================
368  'Not affected'                        The processor is not vulnerable
369  'Vulnerable'                          Vulnerable, no mitigation
370  'Mitigation: Full generic retpoline'  Software-focused mitigation
371  'Mitigation: Full AMD retpoline'      AMD-specific software mitigation
372  'Mitigation: Enhanced IBRS'           Hardware-focused mitigation
373  ====================================  =================================
374
375  - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is
376    used to protect against Spectre variant 2 attacks when calling firmware (x86 only).
377
378  ========== =============================================================
379  'IBRS_FW'  Protection against user program attacks when calling firmware
380  ========== =============================================================
381
382  - Indirect branch prediction barrier (IBPB) status for protection between
383    processes of different users. This feature can be controlled through
384    prctl() per process, or through kernel command line options. This is
385    an x86 only feature. For more details see below.
386
387  ===================   ========================================================
388  'IBPB: disabled'      IBPB unused
389  'IBPB: always-on'     Use IBPB on all tasks
390  'IBPB: conditional'   Use IBPB on SECCOMP or indirect branch restricted tasks
391  ===================   ========================================================
392
393  - Single threaded indirect branch prediction (STIBP) status for protection
394    between different hyper threads. This feature can be controlled through
395    prctl per process, or through kernel command line options. This is x86
396    only feature. For more details see below.
397
398  ====================  ========================================================
399  'STIBP: disabled'     STIBP unused
400  'STIBP: forced'       Use STIBP on all tasks
401  'STIBP: conditional'  Use STIBP on SECCOMP or indirect branch restricted tasks
402  ====================  ========================================================
403
404  - Return stack buffer (RSB) protection status:
405
406  =============   ===========================================
407  'RSB filling'   Protection of RSB on context switch enabled
408  =============   ===========================================
409
410Full mitigation might require a microcode update from the CPU
411vendor. When the necessary microcode is not available, the kernel will
412report vulnerability.
413
414Turning on mitigation for Spectre variant 1 and Spectre variant 2
415-----------------------------------------------------------------
416
4171. Kernel mitigation
418^^^^^^^^^^^^^^^^^^^^
419
420Spectre variant 1
421~~~~~~~~~~~~~~~~~
422
423   For the Spectre variant 1, vulnerable kernel code (as determined
424   by code audit or scanning tools) is annotated on a case by case
425   basis to use nospec accessor macros for bounds clipping :ref:`[2]
426   <spec_ref2>` to avoid any usable disclosure gadgets. However, it may
427   not cover all attack vectors for Spectre variant 1.
428
429   Copy-from-user code has an LFENCE barrier to prevent the access_ok()
430   check from being mis-speculated.  The barrier is done by the
431   barrier_nospec() macro.
432
433   For the swapgs variant of Spectre variant 1, LFENCE barriers are
434   added to interrupt, exception and NMI entry where needed.  These
435   barriers are done by the FENCE_SWAPGS_KERNEL_ENTRY and
436   FENCE_SWAPGS_USER_ENTRY macros.
437
438Spectre variant 2
439~~~~~~~~~~~~~~~~~
440
441   For Spectre variant 2 mitigation, the compiler turns indirect calls or
442   jumps in the kernel into equivalent return trampolines (retpolines)
443   :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target
444   addresses.  Speculative execution paths under retpolines are trapped
445   in an infinite loop to prevent any speculative execution jumping to
446   a gadget.
447
448   To turn on retpoline mitigation on a vulnerable CPU, the kernel
449   needs to be compiled with a gcc compiler that supports the
450   -mindirect-branch=thunk-extern -mindirect-branch-register options.
451   If the kernel is compiled with a Clang compiler, the compiler needs
452   to support -mretpoline-external-thunk option.  The kernel config
453   CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with
454   the latest updated microcode.
455
456   On Intel Skylake-era systems the mitigation covers most, but not all,
457   cases. See :ref:`[3] <spec_ref3>` for more details.
458
459   On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced
460   IBRS on x86), retpoline is automatically disabled at run time.
461
462   The retpoline mitigation is turned on by default on vulnerable
463   CPUs. It can be forced on or off by the administrator
464   via the kernel command line and sysfs control files. See
465   :ref:`spectre_mitigation_control_command_line`.
466
467   On x86, indirect branch restricted speculation is turned on by default
468   before invoking any firmware code to prevent Spectre variant 2 exploits
469   using the firmware.
470
471   Using kernel address space randomization (CONFIG_RANDOMIZE_BASE=y
472   and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes
473   attacks on the kernel generally more difficult.
474
4752. User program mitigation
476^^^^^^^^^^^^^^^^^^^^^^^^^^
477
478   User programs can mitigate Spectre variant 1 using LFENCE or "bounds
479   clipping". For more details see :ref:`[2] <spec_ref2>`.
480
481   For Spectre variant 2 mitigation, individual user programs
482   can be compiled with return trampolines for indirect branches.
483   This protects them from consuming poisoned entries in the branch
484   target buffer left by malicious software.  Alternatively, the
485   programs can disable their indirect branch speculation via prctl()
486   (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
487   On x86, this will turn on STIBP to guard against attacks from the
488   sibling thread when the user program is running, and use IBPB to
489   flush the branch target buffer when switching to/from the program.
490
491   Restricting indirect branch speculation on a user program will
492   also prevent the program from launching a variant 2 attack
493   on x86.  Administrators can change that behavior via the kernel
494   command line and sysfs control files.
495   See :ref:`spectre_mitigation_control_command_line`.
496
497   Programs that disable their indirect branch speculation will have
498   more overhead and run slower.
499
500   User programs should use address space randomization
501   (/proc/sys/kernel/randomize_va_space = 1 or 2) to make attacks more
502   difficult.
503
5043. VM mitigation
505^^^^^^^^^^^^^^^^
506
507   Within the kernel, Spectre variant 1 attacks from rogue guests are
508   mitigated on a case by case basis in VM exit paths. Vulnerable code
509   uses nospec accessor macros for "bounds clipping", to avoid any
510   usable disclosure gadgets.  However, this may not cover all variant
511   1 attack vectors.
512
513   For Spectre variant 2 attacks from rogue guests to the kernel, the
514   Linux kernel uses retpoline or Enhanced IBRS to prevent consumption of
515   poisoned entries in branch target buffer left by rogue guests.  It also
516   flushes the return stack buffer on every VM exit to prevent a return
517   stack buffer underflow so poisoned branch target buffer could be used,
518   or attacker guests leaving poisoned entries in the return stack buffer.
519
520   To mitigate guest-to-guest attacks in the same CPU hardware thread,
521   the branch target buffer is sanitized by flushing before switching
522   to a new guest on a CPU.
523
524   The above mitigations are turned on by default on vulnerable CPUs.
525
526   To mitigate guest-to-guest attacks from sibling thread when SMT is
527   in use, an untrusted guest running in the sibling thread can have
528   its indirect branch speculation disabled by administrator via prctl().
529
530   The kernel also allows guests to use any microcode based mitigation
531   they choose to use (such as IBPB or STIBP on x86) to protect themselves.
532
533.. _spectre_mitigation_control_command_line:
534
535Mitigation control on the kernel command line
536---------------------------------------------
537
538Spectre variant 2 mitigation can be disabled or force enabled at the
539kernel command line.
540
541	nospectre_v1
542
543		[X86,PPC] Disable mitigations for Spectre Variant 1
544		(bounds check bypass). With this option data leaks are
545		possible in the system.
546
547	nospectre_v2
548
549		[X86] Disable all mitigations for the Spectre variant 2
550		(indirect branch prediction) vulnerability. System may
551		allow data leaks with this option, which is equivalent
552		to spectre_v2=off.
553
554
555        spectre_v2=
556
557		[X86] Control mitigation of Spectre variant 2
558		(indirect branch speculation) vulnerability.
559		The default operation protects the kernel from
560		user space attacks.
561
562		on
563			unconditionally enable, implies
564			spectre_v2_user=on
565		off
566			unconditionally disable, implies
567		        spectre_v2_user=off
568		auto
569			kernel detects whether your CPU model is
570		        vulnerable
571
572		Selecting 'on' will, and 'auto' may, choose a
573		mitigation method at run time according to the
574		CPU, the available microcode, the setting of the
575		CONFIG_RETPOLINE configuration option, and the
576		compiler with which the kernel was built.
577
578		Selecting 'on' will also enable the mitigation
579		against user space to user space task attacks.
580
581		Selecting 'off' will disable both the kernel and
582		the user space protections.
583
584		Specific mitigations can also be selected manually:
585
586		retpoline
587					replace indirect branches
588		retpoline,generic
589					google's original retpoline
590		retpoline,amd
591					AMD-specific minimal thunk
592
593		Not specifying this option is equivalent to
594		spectre_v2=auto.
595
596		In general the kernel by default selects
597		reasonable mitigations for the current CPU. To
598		disable Spectre variant 2 mitigations, boot with
599		spectre_v2=off. Spectre variant 1 mitigations
600		cannot be disabled.
601
602For spectre_v2_user see :doc:`/admin-guide/kernel-parameters`.
603
604Mitigation selection guide
605--------------------------
606
6071. Trusted userspace
608^^^^^^^^^^^^^^^^^^^^
609
610   If all userspace applications are from trusted sources and do not
611   execute externally supplied untrusted code, then the mitigations can
612   be disabled.
613
6142. Protect sensitive programs
615^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
616
617   For security-sensitive programs that have secrets (e.g. crypto
618   keys), protection against Spectre variant 2 can be put in place by
619   disabling indirect branch speculation when the program is running
620   (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
621
6223. Sandbox untrusted programs
623^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
624
625   Untrusted programs that could be a source of attacks can be cordoned
626   off by disabling their indirect branch speculation when they are run
627   (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
628   This prevents untrusted programs from polluting the branch target
629   buffer.  This behavior can be changed via the kernel command line
630   and sysfs control files. See
631   :ref:`spectre_mitigation_control_command_line`.
632
6333. High security mode
634^^^^^^^^^^^^^^^^^^^^^
635
636   All Spectre variant 2 mitigations can be forced on
637   at boot time for all programs (See the "on" option in
638   :ref:`spectre_mitigation_control_command_line`).  This will add
639   overhead as indirect branch speculations for all programs will be
640   restricted.
641
642   On x86, branch target buffer will be flushed with IBPB when switching
643   to a new program. STIBP is left on all the time to protect programs
644   against variant 2 attacks originating from programs running on
645   sibling threads.
646
647   Alternatively, STIBP can be used only when running programs
648   whose indirect branch speculation is explicitly disabled,
649   while IBPB is still used all the time when switching to a new
650   program to clear the branch target buffer (See "ibpb" option in
651   :ref:`spectre_mitigation_control_command_line`).  This "ibpb" option
652   has less performance cost than the "on" option, which leaves STIBP
653   on all the time.
654
655References on Spectre
656---------------------
657
658Intel white papers:
659
660.. _spec_ref1:
661
662[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>`_.
663
664.. _spec_ref2:
665
666[2] `Bounds check bypass <https://software.intel.com/security-software-guidance/software-guidance/bounds-check-bypass>`_.
667
668.. _spec_ref3:
669
670[3] `Deep dive: Retpoline: A branch target injection mitigation <https://software.intel.com/security-software-guidance/insights/deep-dive-retpoline-branch-target-injection-mitigation>`_.
671
672.. _spec_ref4:
673
674[4] `Deep Dive: Single Thread Indirect Branch Predictors <https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors>`_.
675
676AMD white papers:
677
678.. _spec_ref5:
679
680[5] `AMD64 technology indirect branch control extension <https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf>`_.
681
682.. _spec_ref6:
683
684[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf>`_.
685
686ARM white papers:
687
688.. _spec_ref7:
689
690[7] `Cache speculation side-channels <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/download-the-whitepaper>`_.
691
692.. _spec_ref8:
693
694[8] `Cache speculation issues update <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/latest-updates/cache-speculation-issues-update>`_.
695
696Google white paper:
697
698.. _spec_ref9:
699
700[9] `Retpoline: a software construct for preventing branch-target-injection <https://support.google.com/faqs/answer/7625886>`_.
701
702MIPS white paper:
703
704.. _spec_ref10:
705
706[10] `MIPS: response on speculative execution and side channel vulnerabilities <https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/>`_.
707
708Academic papers:
709
710.. _spec_ref11:
711
712[11] `Spectre Attacks: Exploiting Speculative Execution <https://spectreattack.com/spectre.pdf>`_.
713
714.. _spec_ref12:
715
716[12] `NetSpectre: Read Arbitrary Memory over Network <https://arxiv.org/abs/1807.10535>`_.
717
718.. _spec_ref13:
719
720[13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://www.usenix.org/system/files/conference/woot18/woot18-paper-koruyeh.pdf>`_.
721