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