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:`[6] <spec_ref6>`
64:ref:`[7] <spec_ref7>` :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
134Yet another variant 2 attack vector is for the attacker to poison the
135Branch History Buffer (BHB) to speculatively steer an indirect branch
136to a specific Branch Target Buffer (BTB) entry, even if the entry isn't
137associated with the source address of the indirect branch. Specifically,
138the BHB might be shared across privilege levels even in the presence of
139Enhanced IBRS.
140
141Currently the only known real-world BHB attack vector is via
142unprivileged eBPF. Therefore, it's highly recommended to not enable
143unprivileged eBPF, especially when eIBRS is used (without retpolines).
144For a full mitigation against BHB attacks, it's recommended to use
145retpolines (or eIBRS combined with retpolines).
146
147Attack scenarios
148----------------
149
150The following list of attack scenarios have been anticipated, but may
151not cover all possible attack vectors.
152
1531. A user process attacking the kernel
154^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
155
156Spectre variant 1
157~~~~~~~~~~~~~~~~~
158
159   The attacker passes a parameter to the kernel via a register or
160   via a known address in memory during a syscall. Such parameter may
161   be used later by the kernel as an index to an array or to derive
162   a pointer for a Spectre variant 1 attack.  The index or pointer
163   is invalid, but bound checks are bypassed in the code branch taken
164   for speculative execution. This could cause privileged memory to be
165   accessed and leaked.
166
167   For kernel code that has been identified where data pointers could
168   potentially be influenced for Spectre attacks, new "nospec" accessor
169   macros are used to prevent speculative loading of data.
170
171Spectre variant 1 (swapgs)
172~~~~~~~~~~~~~~~~~~~~~~~~~~
173
174   An attacker can train the branch predictor to speculatively skip the
175   swapgs path for an interrupt or exception.  If they initialize
176   the GS register to a user-space value, if the swapgs is speculatively
177   skipped, subsequent GS-related percpu accesses in the speculation
178   window will be done with the attacker-controlled GS value.  This
179   could cause privileged memory to be accessed and leaked.
180
181   For example:
182
183   ::
184
185     if (coming from user space)
186         swapgs
187     mov %gs:<percpu_offset>, %reg
188     mov (%reg), %reg1
189
190   When coming from user space, the CPU can speculatively skip the
191   swapgs, and then do a speculative percpu load using the user GS
192   value.  So the user can speculatively force a read of any kernel
193   value.  If a gadget exists which uses the percpu value as an address
194   in another load/store, then the contents of the kernel value may
195   become visible via an L1 side channel attack.
196
197   A similar attack exists when coming from kernel space.  The CPU can
198   speculatively do the swapgs, causing the user GS to get used for the
199   rest of the speculative window.
200
201Spectre variant 2
202~~~~~~~~~~~~~~~~~
203
204   A spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch
205   target buffer (BTB) before issuing syscall to launch an attack.
206   After entering the kernel, the kernel could use the poisoned branch
207   target buffer on indirect jump and jump to gadget code in speculative
208   execution.
209
210   If an attacker tries to control the memory addresses leaked during
211   speculative execution, he would also need to pass a parameter to the
212   gadget, either through a register or a known address in memory. After
213   the gadget has executed, he can measure the side effect.
214
215   The kernel can protect itself against consuming poisoned branch
216   target buffer entries by using return trampolines (also known as
217   "retpoline") :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` for all
218   indirect branches. Return trampolines trap speculative execution paths
219   to prevent jumping to gadget code during speculative execution.
220   x86 CPUs with Enhanced Indirect Branch Restricted Speculation
221   (Enhanced IBRS) available in hardware should use the feature to
222   mitigate Spectre variant 2 instead of retpoline. Enhanced IBRS is
223   more efficient than retpoline.
224
225   There may be gadget code in firmware which could be exploited with
226   Spectre variant 2 attack by a rogue user process. To mitigate such
227   attacks on x86, Indirect Branch Restricted Speculation (IBRS) feature
228   is turned on before the kernel invokes any firmware code.
229
2302. A user process attacking another user process
231^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
232
233   A malicious user process can try to attack another user process,
234   either via a context switch on the same hardware thread, or from the
235   sibling hyperthread sharing a physical processor core on simultaneous
236   multi-threading (SMT) system.
237
238   Spectre variant 1 attacks generally require passing parameters
239   between the processes, which needs a data passing relationship, such
240   as remote procedure calls (RPC).  Those parameters are used in gadget
241   code to derive invalid data pointers accessing privileged memory in
242   the attacked process.
243
244   Spectre variant 2 attacks can be launched from a rogue process by
245   :ref:`poisoning <poison_btb>` the branch target buffer.  This can
246   influence the indirect branch targets for a victim process that either
247   runs later on the same hardware thread, or running concurrently on
248   a sibling hardware thread sharing the same physical core.
249
250   A user process can protect itself against Spectre variant 2 attacks
251   by using the prctl() syscall to disable indirect branch speculation
252   for itself.  An administrator can also cordon off an unsafe process
253   from polluting the branch target buffer by disabling the process's
254   indirect branch speculation. This comes with a performance cost
255   from not using indirect branch speculation and clearing the branch
256   target buffer.  When SMT is enabled on x86, for a process that has
257   indirect branch speculation disabled, Single Threaded Indirect Branch
258   Predictors (STIBP) :ref:`[4] <spec_ref4>` are turned on to prevent the
259   sibling thread from controlling branch target buffer.  In addition,
260   the Indirect Branch Prediction Barrier (IBPB) is issued to clear the
261   branch target buffer when context switching to and from such process.
262
263   On x86, the return stack buffer is stuffed on context switch.
264   This prevents the branch target buffer from being used for branch
265   prediction when the return stack buffer underflows while switching to
266   a deeper call stack. Any poisoned entries in the return stack buffer
267   left by the previous process will also be cleared.
268
269   User programs should use address space randomization to make attacks
270   more difficult (Set /proc/sys/kernel/randomize_va_space = 1 or 2).
271
2723. A virtualized guest attacking the host
273^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
274
275   The attack mechanism is similar to how user processes attack the
276   kernel.  The kernel is entered via hyper-calls or other virtualization
277   exit paths.
278
279   For Spectre variant 1 attacks, rogue guests can pass parameters
280   (e.g. in registers) via hyper-calls to derive invalid pointers to
281   speculate into privileged memory after entering the kernel.  For places
282   where such kernel code has been identified, nospec accessor macros
283   are used to stop speculative memory access.
284
285   For Spectre variant 2 attacks, rogue guests can :ref:`poison
286   <poison_btb>` the branch target buffer or return stack buffer, causing
287   the kernel to jump to gadget code in the speculative execution paths.
288
289   To mitigate variant 2, the host kernel can use return trampolines
290   for indirect branches to bypass the poisoned branch target buffer,
291   and flushing the return stack buffer on VM exit.  This prevents rogue
292   guests from affecting indirect branching in the host kernel.
293
294   To protect host processes from rogue guests, host processes can have
295   indirect branch speculation disabled via prctl().  The branch target
296   buffer is cleared before context switching to such processes.
297
2984. A virtualized guest attacking other guest
299^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
300
301   A rogue guest may attack another guest to get data accessible by the
302   other guest.
303
304   Spectre variant 1 attacks are possible if parameters can be passed
305   between guests.  This may be done via mechanisms such as shared memory
306   or message passing.  Such parameters could be used to derive data
307   pointers to privileged data in guest.  The privileged data could be
308   accessed by gadget code in the victim's speculation paths.
309
310   Spectre variant 2 attacks can be launched from a rogue guest by
311   :ref:`poisoning <poison_btb>` the branch target buffer or the return
312   stack buffer. Such poisoned entries could be used to influence
313   speculation execution paths in the victim guest.
314
315   Linux kernel mitigates attacks to other guests running in the same
316   CPU hardware thread by flushing the return stack buffer on VM exit,
317   and clearing the branch target buffer before switching to a new guest.
318
319   If SMT is used, Spectre variant 2 attacks from an untrusted guest
320   in the sibling hyperthread can be mitigated by the administrator,
321   by turning off the unsafe guest's indirect branch speculation via
322   prctl().  A guest can also protect itself by turning on microcode
323   based mitigations (such as IBPB or STIBP on x86) within the guest.
324
325.. _spectre_sys_info:
326
327Spectre system information
328--------------------------
329
330The Linux kernel provides a sysfs interface to enumerate the current
331mitigation status of the system for Spectre: whether the system is
332vulnerable, and which mitigations are active.
333
334The sysfs file showing Spectre variant 1 mitigation status is:
335
336   /sys/devices/system/cpu/vulnerabilities/spectre_v1
337
338The possible values in this file are:
339
340  .. list-table::
341
342     * - 'Not affected'
343       - The processor is not vulnerable.
344     * - 'Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers'
345       - The swapgs protections are disabled; otherwise it has
346         protection in the kernel on a case by case base with explicit
347         pointer sanitation and usercopy LFENCE barriers.
348     * - 'Mitigation: usercopy/swapgs barriers and __user pointer sanitization'
349       - Protection in the kernel on a case by case base with explicit
350         pointer sanitation, usercopy LFENCE barriers, and swapgs LFENCE
351         barriers.
352
353However, the protections are put in place on a case by case basis,
354and there is no guarantee that all possible attack vectors for Spectre
355variant 1 are covered.
356
357The spectre_v2 kernel file reports if the kernel has been compiled with
358retpoline mitigation or if the CPU has hardware mitigation, and if the
359CPU has support for additional process-specific mitigation.
360
361This file also reports CPU features enabled by microcode to mitigate
362attack between user processes:
363
3641. Indirect Branch Prediction Barrier (IBPB) to add additional
365   isolation between processes of different users.
3662. Single Thread Indirect Branch Predictors (STIBP) to add additional
367   isolation between CPU threads running on the same core.
368
369These CPU features may impact performance when used and can be enabled
370per process on a case-by-case base.
371
372The sysfs file showing Spectre variant 2 mitigation status is:
373
374   /sys/devices/system/cpu/vulnerabilities/spectre_v2
375
376The possible values in this file are:
377
378  - Kernel status:
379
380  ========================================  =================================
381  'Not affected'                            The processor is not vulnerable
382  'Mitigation: None'                        Vulnerable, no mitigation
383  'Mitigation: Retpolines'                  Use Retpoline thunks
384  'Mitigation: LFENCE'                      Use LFENCE instructions
385  'Mitigation: Enhanced IBRS'               Hardware-focused mitigation
386  'Mitigation: Enhanced IBRS + Retpolines'  Hardware-focused + Retpolines
387  'Mitigation: Enhanced IBRS + LFENCE'      Hardware-focused + LFENCE
388  ========================================  =================================
389
390  - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is
391    used to protect against Spectre variant 2 attacks when calling firmware (x86 only).
392
393  ========== =============================================================
394  'IBRS_FW'  Protection against user program attacks when calling firmware
395  ========== =============================================================
396
397  - Indirect branch prediction barrier (IBPB) status for protection between
398    processes of different users. This feature can be controlled through
399    prctl() per process, or through kernel command line options. This is
400    an x86 only feature. For more details see below.
401
402  ===================   ========================================================
403  'IBPB: disabled'      IBPB unused
404  'IBPB: always-on'     Use IBPB on all tasks
405  'IBPB: conditional'   Use IBPB on SECCOMP or indirect branch restricted tasks
406  ===================   ========================================================
407
408  - Single threaded indirect branch prediction (STIBP) status for protection
409    between different hyper threads. This feature can be controlled through
410    prctl per process, or through kernel command line options. This is x86
411    only feature. For more details see below.
412
413  ====================  ========================================================
414  'STIBP: disabled'     STIBP unused
415  'STIBP: forced'       Use STIBP on all tasks
416  'STIBP: conditional'  Use STIBP on SECCOMP or indirect branch restricted tasks
417  ====================  ========================================================
418
419  - Return stack buffer (RSB) protection status:
420
421  =============   ===========================================
422  'RSB filling'   Protection of RSB on context switch enabled
423  =============   ===========================================
424
425  - EIBRS Post-barrier Return Stack Buffer (PBRSB) protection status:
426
427  ===========================  =======================================================
428  'PBRSB-eIBRS: SW sequence'   CPU is affected and protection of RSB on VMEXIT enabled
429  'PBRSB-eIBRS: Vulnerable'    CPU is vulnerable
430  'PBRSB-eIBRS: Not affected'  CPU is not affected by PBRSB
431  ===========================  =======================================================
432
433Full mitigation might require a microcode update from the CPU
434vendor. When the necessary microcode is not available, the kernel will
435report vulnerability.
436
437Turning on mitigation for Spectre variant 1 and Spectre variant 2
438-----------------------------------------------------------------
439
4401. Kernel mitigation
441^^^^^^^^^^^^^^^^^^^^
442
443Spectre variant 1
444~~~~~~~~~~~~~~~~~
445
446   For the Spectre variant 1, vulnerable kernel code (as determined
447   by code audit or scanning tools) is annotated on a case by case
448   basis to use nospec accessor macros for bounds clipping :ref:`[2]
449   <spec_ref2>` to avoid any usable disclosure gadgets. However, it may
450   not cover all attack vectors for Spectre variant 1.
451
452   Copy-from-user code has an LFENCE barrier to prevent the access_ok()
453   check from being mis-speculated.  The barrier is done by the
454   barrier_nospec() macro.
455
456   For the swapgs variant of Spectre variant 1, LFENCE barriers are
457   added to interrupt, exception and NMI entry where needed.  These
458   barriers are done by the FENCE_SWAPGS_KERNEL_ENTRY and
459   FENCE_SWAPGS_USER_ENTRY macros.
460
461Spectre variant 2
462~~~~~~~~~~~~~~~~~
463
464   For Spectre variant 2 mitigation, the compiler turns indirect calls or
465   jumps in the kernel into equivalent return trampolines (retpolines)
466   :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target
467   addresses.  Speculative execution paths under retpolines are trapped
468   in an infinite loop to prevent any speculative execution jumping to
469   a gadget.
470
471   To turn on retpoline mitigation on a vulnerable CPU, the kernel
472   needs to be compiled with a gcc compiler that supports the
473   -mindirect-branch=thunk-extern -mindirect-branch-register options.
474   If the kernel is compiled with a Clang compiler, the compiler needs
475   to support -mretpoline-external-thunk option.  The kernel config
476   CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with
477   the latest updated microcode.
478
479   On Intel Skylake-era systems the mitigation covers most, but not all,
480   cases. See :ref:`[3] <spec_ref3>` for more details.
481
482   On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced
483   IBRS on x86), retpoline is automatically disabled at run time.
484
485   The retpoline mitigation is turned on by default on vulnerable
486   CPUs. It can be forced on or off by the administrator
487   via the kernel command line and sysfs control files. See
488   :ref:`spectre_mitigation_control_command_line`.
489
490   On x86, indirect branch restricted speculation is turned on by default
491   before invoking any firmware code to prevent Spectre variant 2 exploits
492   using the firmware.
493
494   Using kernel address space randomization (CONFIG_RANDOMIZE_BASE=y
495   and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes
496   attacks on the kernel generally more difficult.
497
4982. User program mitigation
499^^^^^^^^^^^^^^^^^^^^^^^^^^
500
501   User programs can mitigate Spectre variant 1 using LFENCE or "bounds
502   clipping". For more details see :ref:`[2] <spec_ref2>`.
503
504   For Spectre variant 2 mitigation, individual user programs
505   can be compiled with return trampolines for indirect branches.
506   This protects them from consuming poisoned entries in the branch
507   target buffer left by malicious software.  Alternatively, the
508   programs can disable their indirect branch speculation via prctl()
509   (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
510   On x86, this will turn on STIBP to guard against attacks from the
511   sibling thread when the user program is running, and use IBPB to
512   flush the branch target buffer when switching to/from the program.
513
514   Restricting indirect branch speculation on a user program will
515   also prevent the program from launching a variant 2 attack
516   on x86.  Administrators can change that behavior via the kernel
517   command line and sysfs control files.
518   See :ref:`spectre_mitigation_control_command_line`.
519
520   Programs that disable their indirect branch speculation will have
521   more overhead and run slower.
522
523   User programs should use address space randomization
524   (/proc/sys/kernel/randomize_va_space = 1 or 2) to make attacks more
525   difficult.
526
5273. VM mitigation
528^^^^^^^^^^^^^^^^
529
530   Within the kernel, Spectre variant 1 attacks from rogue guests are
531   mitigated on a case by case basis in VM exit paths. Vulnerable code
532   uses nospec accessor macros for "bounds clipping", to avoid any
533   usable disclosure gadgets.  However, this may not cover all variant
534   1 attack vectors.
535
536   For Spectre variant 2 attacks from rogue guests to the kernel, the
537   Linux kernel uses retpoline or Enhanced IBRS to prevent consumption of
538   poisoned entries in branch target buffer left by rogue guests.  It also
539   flushes the return stack buffer on every VM exit to prevent a return
540   stack buffer underflow so poisoned branch target buffer could be used,
541   or attacker guests leaving poisoned entries in the return stack buffer.
542
543   To mitigate guest-to-guest attacks in the same CPU hardware thread,
544   the branch target buffer is sanitized by flushing before switching
545   to a new guest on a CPU.
546
547   The above mitigations are turned on by default on vulnerable CPUs.
548
549   To mitigate guest-to-guest attacks from sibling thread when SMT is
550   in use, an untrusted guest running in the sibling thread can have
551   its indirect branch speculation disabled by administrator via prctl().
552
553   The kernel also allows guests to use any microcode based mitigation
554   they choose to use (such as IBPB or STIBP on x86) to protect themselves.
555
556.. _spectre_mitigation_control_command_line:
557
558Mitigation control on the kernel command line
559---------------------------------------------
560
561Spectre variant 2 mitigation can be disabled or force enabled at the
562kernel command line.
563
564	nospectre_v1
565
566		[X86,PPC] Disable mitigations for Spectre Variant 1
567		(bounds check bypass). With this option data leaks are
568		possible in the system.
569
570	nospectre_v2
571
572		[X86] Disable all mitigations for the Spectre variant 2
573		(indirect branch prediction) vulnerability. System may
574		allow data leaks with this option, which is equivalent
575		to spectre_v2=off.
576
577
578        spectre_v2=
579
580		[X86] Control mitigation of Spectre variant 2
581		(indirect branch speculation) vulnerability.
582		The default operation protects the kernel from
583		user space attacks.
584
585		on
586			unconditionally enable, implies
587			spectre_v2_user=on
588		off
589			unconditionally disable, implies
590		        spectre_v2_user=off
591		auto
592			kernel detects whether your CPU model is
593		        vulnerable
594
595		Selecting 'on' will, and 'auto' may, choose a
596		mitigation method at run time according to the
597		CPU, the available microcode, the setting of the
598		CONFIG_RETPOLINE configuration option, and the
599		compiler with which the kernel was built.
600
601		Selecting 'on' will also enable the mitigation
602		against user space to user space task attacks.
603
604		Selecting 'off' will disable both the kernel and
605		the user space protections.
606
607		Specific mitigations can also be selected manually:
608
609                retpoline               auto pick between generic,lfence
610                retpoline,generic       Retpolines
611                retpoline,lfence        LFENCE; indirect branch
612                retpoline,amd           alias for retpoline,lfence
613                eibrs                   enhanced IBRS
614                eibrs,retpoline         enhanced IBRS + Retpolines
615                eibrs,lfence            enhanced IBRS + LFENCE
616
617		Not specifying this option is equivalent to
618		spectre_v2=auto.
619
620		In general the kernel by default selects
621		reasonable mitigations for the current CPU. To
622		disable Spectre variant 2 mitigations, boot with
623		spectre_v2=off. Spectre variant 1 mitigations
624		cannot be disabled.
625
626For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt
627
628Mitigation selection guide
629--------------------------
630
6311. Trusted userspace
632^^^^^^^^^^^^^^^^^^^^
633
634   If all userspace applications are from trusted sources and do not
635   execute externally supplied untrusted code, then the mitigations can
636   be disabled.
637
6382. Protect sensitive programs
639^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
640
641   For security-sensitive programs that have secrets (e.g. crypto
642   keys), protection against Spectre variant 2 can be put in place by
643   disabling indirect branch speculation when the program is running
644   (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
645
6463. Sandbox untrusted programs
647^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
648
649   Untrusted programs that could be a source of attacks can be cordoned
650   off by disabling their indirect branch speculation when they are run
651   (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
652   This prevents untrusted programs from polluting the branch target
653   buffer.  This behavior can be changed via the kernel command line
654   and sysfs control files. See
655   :ref:`spectre_mitigation_control_command_line`.
656
6573. High security mode
658^^^^^^^^^^^^^^^^^^^^^
659
660   All Spectre variant 2 mitigations can be forced on
661   at boot time for all programs (See the "on" option in
662   :ref:`spectre_mitigation_control_command_line`).  This will add
663   overhead as indirect branch speculations for all programs will be
664   restricted.
665
666   On x86, branch target buffer will be flushed with IBPB when switching
667   to a new program. STIBP is left on all the time to protect programs
668   against variant 2 attacks originating from programs running on
669   sibling threads.
670
671   Alternatively, STIBP can be used only when running programs
672   whose indirect branch speculation is explicitly disabled,
673   while IBPB is still used all the time when switching to a new
674   program to clear the branch target buffer (See "ibpb" option in
675   :ref:`spectre_mitigation_control_command_line`).  This "ibpb" option
676   has less performance cost than the "on" option, which leaves STIBP
677   on all the time.
678
679References on Spectre
680---------------------
681
682Intel white papers:
683
684.. _spec_ref1:
685
686[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>`_.
687
688.. _spec_ref2:
689
690[2] `Bounds check bypass <https://software.intel.com/security-software-guidance/software-guidance/bounds-check-bypass>`_.
691
692.. _spec_ref3:
693
694[3] `Deep dive: Retpoline: A branch target injection mitigation <https://software.intel.com/security-software-guidance/insights/deep-dive-retpoline-branch-target-injection-mitigation>`_.
695
696.. _spec_ref4:
697
698[4] `Deep Dive: Single Thread Indirect Branch Predictors <https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors>`_.
699
700AMD white papers:
701
702.. _spec_ref5:
703
704[5] `AMD64 technology indirect branch control extension <https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf>`_.
705
706.. _spec_ref6:
707
708[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf>`_.
709
710ARM white papers:
711
712.. _spec_ref7:
713
714[7] `Cache speculation side-channels <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/download-the-whitepaper>`_.
715
716.. _spec_ref8:
717
718[8] `Cache speculation issues update <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/latest-updates/cache-speculation-issues-update>`_.
719
720Google white paper:
721
722.. _spec_ref9:
723
724[9] `Retpoline: a software construct for preventing branch-target-injection <https://support.google.com/faqs/answer/7625886>`_.
725
726MIPS white paper:
727
728.. _spec_ref10:
729
730[10] `MIPS: response on speculative execution and side channel vulnerabilities <https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/>`_.
731
732Academic papers:
733
734.. _spec_ref11:
735
736[11] `Spectre Attacks: Exploiting Speculative Execution <https://spectreattack.com/spectre.pdf>`_.
737
738.. _spec_ref12:
739
740[12] `NetSpectre: Read Arbitrary Memory over Network <https://arxiv.org/abs/1807.10535>`_.
741
742.. _spec_ref13:
743
744[13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://www.usenix.org/system/files/conference/woot18/woot18-paper-koruyeh.pdf>`_.
745