Documentation / admin-guide / hw-vuln / spectre.rst

Based on kernel version 5.9. Page generated on 2020-10-14 09:35 EST.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769
.. SPDX-License-Identifier: GPL-2.0

Spectre Side Channels

Spectre is a class of side channel attacks that exploit branch prediction
and speculative execution on modern CPUs to read memory, possibly
bypassing access controls. Speculative execution side channel exploits
do not modify memory but attempt to infer privileged data in the memory.

This document covers Spectre variant 1 and Spectre variant 2.

Affected processors

Speculative execution side channel methods affect a wide range of modern
high performance processors, since most modern high speed processors
use branch prediction and speculative execution.

The following CPUs are vulnerable:

    - Intel Core, Atom, Pentium, and Xeon processors

    - AMD Phenom, EPYC, and Zen processors

    - IBM POWER and zSeries processors

    - Higher end ARM processors

    - Apple CPUs

    - Higher end MIPS CPUs

    - Likely most other high performance CPUs. Contact your CPU vendor for details.

Whether a processor is affected or not can be read out from the Spectre
vulnerability files in sysfs. See :ref:`spectre_sys_info`.

Related CVEs

The following CVE entries describe Spectre variants:

   =============   =======================  ==========================
   CVE-2017-5753   Bounds check bypass      Spectre variant 1
   CVE-2017-5715   Branch target injection  Spectre variant 2
   CVE-2019-1125   Spectre v1 swapgs        Spectre variant 1 (swapgs)
   =============   =======================  ==========================


CPUs use speculative operations to improve performance. That may leave
traces of memory accesses or computations in the processor's caches,
buffers, and branch predictors. Malicious software may be able to
influence the speculative execution paths, and then use the side effects
of the speculative execution in the CPUs' caches and buffers to infer
privileged data touched during the speculative execution.

Spectre variant 1 attacks take advantage of speculative execution of
conditional branches, while Spectre variant 2 attacks use speculative
execution of indirect branches to leak privileged memory.
See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[7] <spec_ref7>`
:ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`.

Spectre variant 1 (Bounds Check Bypass)

The bounds check bypass attack :ref:`[2] <spec_ref2>` takes advantage
of speculative execution that bypasses conditional branch instructions
used for memory access bounds check (e.g. checking if the index of an
array results in memory access within a valid range). This results in
memory accesses to invalid memory (with out-of-bound index) that are
done speculatively before validation checks resolve. Such speculative
memory accesses can leave side effects, creating side channels which
leak information to the attacker.

There are some extensions of Spectre variant 1 attacks for reading data
over the network, see :ref:`[12] <spec_ref12>`. However such attacks
are difficult, low bandwidth, fragile, and are considered low risk.

Note that, despite "Bounds Check Bypass" name, Spectre variant 1 is not
only about user-controlled array bounds checks.  It can affect any
conditional checks.  The kernel entry code interrupt, exception, and NMI
handlers all have conditional swapgs checks.  Those may be problematic
in the context of Spectre v1, as kernel code can speculatively run with
a user GS.

Spectre variant 2 (Branch Target Injection)

The branch target injection attack takes advantage of speculative
execution of indirect branches :ref:`[3] <spec_ref3>`.  The indirect
branch predictors inside the processor used to guess the target of
indirect branches can be influenced by an attacker, causing gadget code
to be speculatively executed, thus exposing sensitive data touched by
the victim. The side effects left in the CPU's caches during speculative
execution can be measured to infer data values.

.. _poison_btb:

In Spectre variant 2 attacks, the attacker can steer speculative indirect
branches in the victim to gadget code by poisoning the branch target
buffer of a CPU used for predicting indirect branch addresses. Such
poisoning could be done by indirect branching into existing code,
with the address offset of the indirect branch under the attacker's
control. Since the branch prediction on impacted hardware does not
fully disambiguate branch address and uses the offset for prediction,
this could cause privileged code's indirect branch to jump to a gadget
code with the same offset.

The most useful gadgets take an attacker-controlled input parameter (such
as a register value) so that the memory read can be controlled. Gadgets
without input parameters might be possible, but the attacker would have
very little control over what memory can be read, reducing the risk of
the attack revealing useful data.

One other variant 2 attack vector is for the attacker to poison the
return stack buffer (RSB) :ref:`[13] <spec_ref13>` to cause speculative
subroutine return instruction execution to go to a gadget.  An attacker's
imbalanced subroutine call instructions might "poison" entries in the
return stack buffer which are later consumed by a victim's subroutine
return instructions.  This attack can be mitigated by flushing the return
stack buffer on context switch, or virtual machine (VM) exit.

On systems with simultaneous multi-threading (SMT), attacks are possible
from the sibling thread, as level 1 cache and branch target buffer
(BTB) may be shared between hardware threads in a CPU core.  A malicious
program running on the sibling thread may influence its peer's BTB to
steer its indirect branch speculations to gadget code, and measure the
speculative execution's side effects left in level 1 cache to infer the
victim's data.

Attack scenarios

The following list of attack scenarios have been anticipated, but may
not cover all possible attack vectors.

1. A user process attacking the kernel

Spectre variant 1

   The attacker passes a parameter to the kernel via a register or
   via a known address in memory during a syscall. Such parameter may
   be used later by the kernel as an index to an array or to derive
   a pointer for a Spectre variant 1 attack.  The index or pointer
   is invalid, but bound checks are bypassed in the code branch taken
   for speculative execution. This could cause privileged memory to be
   accessed and leaked.

   For kernel code that has been identified where data pointers could
   potentially be influenced for Spectre attacks, new "nospec" accessor
   macros are used to prevent speculative loading of data.

Spectre variant 1 (swapgs)

   An attacker can train the branch predictor to speculatively skip the
   swapgs path for an interrupt or exception.  If they initialize
   the GS register to a user-space value, if the swapgs is speculatively
   skipped, subsequent GS-related percpu accesses in the speculation
   window will be done with the attacker-controlled GS value.  This
   could cause privileged memory to be accessed and leaked.

   For example:


     if (coming from user space)
     mov %gs:<percpu_offset>, %reg
     mov (%reg), %reg1

   When coming from user space, the CPU can speculatively skip the
   swapgs, and then do a speculative percpu load using the user GS
   value.  So the user can speculatively force a read of any kernel
   value.  If a gadget exists which uses the percpu value as an address
   in another load/store, then the contents of the kernel value may
   become visible via an L1 side channel attack.

   A similar attack exists when coming from kernel space.  The CPU can
   speculatively do the swapgs, causing the user GS to get used for the
   rest of the speculative window.

Spectre variant 2

   A spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch
   target buffer (BTB) before issuing syscall to launch an attack.
   After entering the kernel, the kernel could use the poisoned branch
   target buffer on indirect jump and jump to gadget code in speculative

   If an attacker tries to control the memory addresses leaked during
   speculative execution, he would also need to pass a parameter to the
   gadget, either through a register or a known address in memory. After
   the gadget has executed, he can measure the side effect.

   The kernel can protect itself against consuming poisoned branch
   target buffer entries by using return trampolines (also known as
   "retpoline") :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` for all
   indirect branches. Return trampolines trap speculative execution paths
   to prevent jumping to gadget code during speculative execution.
   x86 CPUs with Enhanced Indirect Branch Restricted Speculation
   (Enhanced IBRS) available in hardware should use the feature to
   mitigate Spectre variant 2 instead of retpoline. Enhanced IBRS is
   more efficient than retpoline.

   There may be gadget code in firmware which could be exploited with
   Spectre variant 2 attack by a rogue user process. To mitigate such
   attacks on x86, Indirect Branch Restricted Speculation (IBRS) feature
   is turned on before the kernel invokes any firmware code.

2. A user process attacking another user process

   A malicious user process can try to attack another user process,
   either via a context switch on the same hardware thread, or from the
   sibling hyperthread sharing a physical processor core on simultaneous
   multi-threading (SMT) system.

   Spectre variant 1 attacks generally require passing parameters
   between the processes, which needs a data passing relationship, such
   as remote procedure calls (RPC).  Those parameters are used in gadget
   code to derive invalid data pointers accessing privileged memory in
   the attacked process.

   Spectre variant 2 attacks can be launched from a rogue process by
   :ref:`poisoning <poison_btb>` the branch target buffer.  This can
   influence the indirect branch targets for a victim process that either
   runs later on the same hardware thread, or running concurrently on
   a sibling hardware thread sharing the same physical core.

   A user process can protect itself against Spectre variant 2 attacks
   by using the prctl() syscall to disable indirect branch speculation
   for itself.  An administrator can also cordon off an unsafe process
   from polluting the branch target buffer by disabling the process's
   indirect branch speculation. This comes with a performance cost
   from not using indirect branch speculation and clearing the branch
   target buffer.  When SMT is enabled on x86, for a process that has
   indirect branch speculation disabled, Single Threaded Indirect Branch
   Predictors (STIBP) :ref:`[4] <spec_ref4>` are turned on to prevent the
   sibling thread from controlling branch target buffer.  In addition,
   the Indirect Branch Prediction Barrier (IBPB) is issued to clear the
   branch target buffer when context switching to and from such process.

   On x86, the return stack buffer is stuffed on context switch.
   This prevents the branch target buffer from being used for branch
   prediction when the return stack buffer underflows while switching to
   a deeper call stack. Any poisoned entries in the return stack buffer
   left by the previous process will also be cleared.

   User programs should use address space randomization to make attacks
   more difficult (Set /proc/sys/kernel/randomize_va_space = 1 or 2).

3. A virtualized guest attacking the host

   The attack mechanism is similar to how user processes attack the
   kernel.  The kernel is entered via hyper-calls or other virtualization
   exit paths.

   For Spectre variant 1 attacks, rogue guests can pass parameters
   (e.g. in registers) via hyper-calls to derive invalid pointers to
   speculate into privileged memory after entering the kernel.  For places
   where such kernel code has been identified, nospec accessor macros
   are used to stop speculative memory access.

   For Spectre variant 2 attacks, rogue guests can :ref:`poison
   <poison_btb>` the branch target buffer or return stack buffer, causing
   the kernel to jump to gadget code in the speculative execution paths.

   To mitigate variant 2, the host kernel can use return trampolines
   for indirect branches to bypass the poisoned branch target buffer,
   and flushing the return stack buffer on VM exit.  This prevents rogue
   guests from affecting indirect branching in the host kernel.

   To protect host processes from rogue guests, host processes can have
   indirect branch speculation disabled via prctl().  The branch target
   buffer is cleared before context switching to such processes.

4. A virtualized guest attacking other guest

   A rogue guest may attack another guest to get data accessible by the
   other guest.

   Spectre variant 1 attacks are possible if parameters can be passed
   between guests.  This may be done via mechanisms such as shared memory
   or message passing.  Such parameters could be used to derive data
   pointers to privileged data in guest.  The privileged data could be
   accessed by gadget code in the victim's speculation paths.

   Spectre variant 2 attacks can be launched from a rogue guest by
   :ref:`poisoning <poison_btb>` the branch target buffer or the return
   stack buffer. Such poisoned entries could be used to influence
   speculation execution paths in the victim guest.

   Linux kernel mitigates attacks to other guests running in the same
   CPU hardware thread by flushing the return stack buffer on VM exit,
   and clearing the branch target buffer before switching to a new guest.

   If SMT is used, Spectre variant 2 attacks from an untrusted guest
   in the sibling hyperthread can be mitigated by the administrator,
   by turning off the unsafe guest's indirect branch speculation via
   prctl().  A guest can also protect itself by turning on microcode
   based mitigations (such as IBPB or STIBP on x86) within the guest.

.. _spectre_sys_info:

Spectre system information

The Linux kernel provides a sysfs interface to enumerate the current
mitigation status of the system for Spectre: whether the system is
vulnerable, and which mitigations are active.

The sysfs file showing Spectre variant 1 mitigation status is:


The possible values in this file are:

  .. list-table::

     * - 'Not affected'
       - The processor is not vulnerable.
     * - 'Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers'
       - The swapgs protections are disabled; otherwise it has
         protection in the kernel on a case by case base with explicit
         pointer sanitation and usercopy LFENCE barriers.
     * - 'Mitigation: usercopy/swapgs barriers and __user pointer sanitization'
       - Protection in the kernel on a case by case base with explicit
         pointer sanitation, usercopy LFENCE barriers, and swapgs LFENCE

However, the protections are put in place on a case by case basis,
and there is no guarantee that all possible attack vectors for Spectre
variant 1 are covered.

The spectre_v2 kernel file reports if the kernel has been compiled with
retpoline mitigation or if the CPU has hardware mitigation, and if the
CPU has support for additional process-specific mitigation.

This file also reports CPU features enabled by microcode to mitigate
attack between user processes:

1. Indirect Branch Prediction Barrier (IBPB) to add additional
   isolation between processes of different users.
2. Single Thread Indirect Branch Predictors (STIBP) to add additional
   isolation between CPU threads running on the same core.

These CPU features may impact performance when used and can be enabled
per process on a case-by-case base.

The sysfs file showing Spectre variant 2 mitigation status is:


The possible values in this file are:

  - Kernel status:

  ====================================  =================================
  'Not affected'                        The processor is not vulnerable
  'Vulnerable'                          Vulnerable, no mitigation
  'Mitigation: Full generic retpoline'  Software-focused mitigation
  'Mitigation: Full AMD retpoline'      AMD-specific software mitigation
  'Mitigation: Enhanced IBRS'           Hardware-focused mitigation
  ====================================  =================================

  - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is
    used to protect against Spectre variant 2 attacks when calling firmware (x86 only).

  ========== =============================================================
  'IBRS_FW'  Protection against user program attacks when calling firmware
  ========== =============================================================

  - Indirect branch prediction barrier (IBPB) status for protection between
    processes of different users. This feature can be controlled through
    prctl() per process, or through kernel command line options. This is
    an x86 only feature. For more details see below.

  ===================   ========================================================
  'IBPB: disabled'      IBPB unused
  'IBPB: always-on'     Use IBPB on all tasks
  'IBPB: conditional'   Use IBPB on SECCOMP or indirect branch restricted tasks
  ===================   ========================================================

  - Single threaded indirect branch prediction (STIBP) status for protection
    between different hyper threads. This feature can be controlled through
    prctl per process, or through kernel command line options. This is x86
    only feature. For more details see below.

  ====================  ========================================================
  'STIBP: disabled'     STIBP unused
  'STIBP: forced'       Use STIBP on all tasks
  'STIBP: conditional'  Use STIBP on SECCOMP or indirect branch restricted tasks
  ====================  ========================================================

  - Return stack buffer (RSB) protection status:

  =============   ===========================================
  'RSB filling'   Protection of RSB on context switch enabled
  =============   ===========================================

Full mitigation might require a microcode update from the CPU
vendor. When the necessary microcode is not available, the kernel will
report vulnerability.

Turning on mitigation for Spectre variant 1 and Spectre variant 2

1. Kernel mitigation

Spectre variant 1

   For the Spectre variant 1, vulnerable kernel code (as determined
   by code audit or scanning tools) is annotated on a case by case
   basis to use nospec accessor macros for bounds clipping :ref:`[2]
   <spec_ref2>` to avoid any usable disclosure gadgets. However, it may
   not cover all attack vectors for Spectre variant 1.

   Copy-from-user code has an LFENCE barrier to prevent the access_ok()
   check from being mis-speculated.  The barrier is done by the
   barrier_nospec() macro.

   For the swapgs variant of Spectre variant 1, LFENCE barriers are
   added to interrupt, exception and NMI entry where needed.  These
   barriers are done by the FENCE_SWAPGS_KERNEL_ENTRY and

Spectre variant 2

   For Spectre variant 2 mitigation, the compiler turns indirect calls or
   jumps in the kernel into equivalent return trampolines (retpolines)
   :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target
   addresses.  Speculative execution paths under retpolines are trapped
   in an infinite loop to prevent any speculative execution jumping to
   a gadget.

   To turn on retpoline mitigation on a vulnerable CPU, the kernel
   needs to be compiled with a gcc compiler that supports the
   -mindirect-branch=thunk-extern -mindirect-branch-register options.
   If the kernel is compiled with a Clang compiler, the compiler needs
   to support -mretpoline-external-thunk option.  The kernel config
   CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with
   the latest updated microcode.

   On Intel Skylake-era systems the mitigation covers most, but not all,
   cases. See :ref:`[3] <spec_ref3>` for more details.

   On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced
   IBRS on x86), retpoline is automatically disabled at run time.

   The retpoline mitigation is turned on by default on vulnerable
   CPUs. It can be forced on or off by the administrator
   via the kernel command line and sysfs control files. See

   On x86, indirect branch restricted speculation is turned on by default
   before invoking any firmware code to prevent Spectre variant 2 exploits
   using the firmware.

   Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=y
   and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes
   attacks on the kernel generally more difficult.

2. User program mitigation

   User programs can mitigate Spectre variant 1 using LFENCE or "bounds
   clipping". For more details see :ref:`[2] <spec_ref2>`.

   For Spectre variant 2 mitigation, individual user programs
   can be compiled with return trampolines for indirect branches.
   This protects them from consuming poisoned entries in the branch
   target buffer left by malicious software.  Alternatively, the
   programs can disable their indirect branch speculation via prctl()
   (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
   On x86, this will turn on STIBP to guard against attacks from the
   sibling thread when the user program is running, and use IBPB to
   flush the branch target buffer when switching to/from the program.

   Restricting indirect branch speculation on a user program will
   also prevent the program from launching a variant 2 attack
   on x86.  All sand-boxed SECCOMP programs have indirect branch
   speculation restricted by default.  Administrators can change
   that behavior via the kernel command line and sysfs control files.
   See :ref:`spectre_mitigation_control_command_line`.

   Programs that disable their indirect branch speculation will have
   more overhead and run slower.

   User programs should use address space randomization
   (/proc/sys/kernel/randomize_va_space = 1 or 2) to make attacks more

3. VM mitigation

   Within the kernel, Spectre variant 1 attacks from rogue guests are
   mitigated on a case by case basis in VM exit paths. Vulnerable code
   uses nospec accessor macros for "bounds clipping", to avoid any
   usable disclosure gadgets.  However, this may not cover all variant
   1 attack vectors.

   For Spectre variant 2 attacks from rogue guests to the kernel, the
   Linux kernel uses retpoline or Enhanced IBRS to prevent consumption of
   poisoned entries in branch target buffer left by rogue guests.  It also
   flushes the return stack buffer on every VM exit to prevent a return
   stack buffer underflow so poisoned branch target buffer could be used,
   or attacker guests leaving poisoned entries in the return stack buffer.

   To mitigate guest-to-guest attacks in the same CPU hardware thread,
   the branch target buffer is sanitized by flushing before switching
   to a new guest on a CPU.

   The above mitigations are turned on by default on vulnerable CPUs.

   To mitigate guest-to-guest attacks from sibling thread when SMT is
   in use, an untrusted guest running in the sibling thread can have
   its indirect branch speculation disabled by administrator via prctl().

   The kernel also allows guests to use any microcode based mitigation
   they choose to use (such as IBPB or STIBP on x86) to protect themselves.

.. _spectre_mitigation_control_command_line:

Mitigation control on the kernel command line

Spectre variant 2 mitigation can be disabled or force enabled at the
kernel command line.


		[X86,PPC] Disable mitigations for Spectre Variant 1
		(bounds check bypass). With this option data leaks are
		possible in the system.


		[X86] Disable all mitigations for the Spectre variant 2
		(indirect branch prediction) vulnerability. System may
		allow data leaks with this option, which is equivalent
		to spectre_v2=off.


		[X86] Control mitigation of Spectre variant 2
		(indirect branch speculation) vulnerability.
		The default operation protects the kernel from
		user space attacks.

			unconditionally enable, implies
			unconditionally disable, implies
			kernel detects whether your CPU model is

		Selecting 'on' will, and 'auto' may, choose a
		mitigation method at run time according to the
		CPU, the available microcode, the setting of the
		CONFIG_RETPOLINE configuration option, and the
		compiler with which the kernel was built.

		Selecting 'on' will also enable the mitigation
		against user space to user space task attacks.

		Selecting 'off' will disable both the kernel and
		the user space protections.

		Specific mitigations can also be selected manually:

					replace indirect branches
					google's original retpoline
					AMD-specific minimal thunk

		Not specifying this option is equivalent to

For user space mitigation:


		[X86] Control mitigation of Spectre variant 2
		(indirect branch speculation) vulnerability between
		user space tasks

			Unconditionally enable mitigations. Is
			enforced by spectre_v2=on

			Unconditionally disable mitigations. Is
			enforced by spectre_v2=off

			Indirect branch speculation is enabled,
			but mitigation can be enabled via prctl
			per thread. The mitigation control state
			is inherited on fork.

			Like "prctl" above, but only STIBP is
			controlled per thread. IBPB is issued
			always when switching between different user
			space processes.

			Same as "prctl" above, but all seccomp
			threads will enable the mitigation unless
			they explicitly opt out.

			Like "seccomp" above, but only STIBP is
			controlled per thread. IBPB is issued
			always when switching between different
			user space processes.

			Kernel selects the mitigation depending on
			the available CPU features and vulnerability.

		Default mitigation:
		If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"

		Not specifying this option is equivalent to

		In general the kernel by default selects
		reasonable mitigations for the current CPU. To
		disable Spectre variant 2 mitigations, boot with
		spectre_v2=off. Spectre variant 1 mitigations
		cannot be disabled.

Mitigation selection guide

1. Trusted userspace

   If all userspace applications are from trusted sources and do not
   execute externally supplied untrusted code, then the mitigations can
   be disabled.

2. Protect sensitive programs

   For security-sensitive programs that have secrets (e.g. crypto
   keys), protection against Spectre variant 2 can be put in place by
   disabling indirect branch speculation when the program is running
   (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).

3. Sandbox untrusted programs

   Untrusted programs that could be a source of attacks can be cordoned
   off by disabling their indirect branch speculation when they are run
   (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
   This prevents untrusted programs from polluting the branch target
   buffer.  All programs running in SECCOMP sandboxes have indirect
   branch speculation restricted by default. This behavior can be
   changed via the kernel command line and sysfs control files. See

3. High security mode

   All Spectre variant 2 mitigations can be forced on
   at boot time for all programs (See the "on" option in
   :ref:`spectre_mitigation_control_command_line`).  This will add
   overhead as indirect branch speculations for all programs will be

   On x86, branch target buffer will be flushed with IBPB when switching
   to a new program. STIBP is left on all the time to protect programs
   against variant 2 attacks originating from programs running on
   sibling threads.

   Alternatively, STIBP can be used only when running programs
   whose indirect branch speculation is explicitly disabled,
   while IBPB is still used all the time when switching to a new
   program to clear the branch target buffer (See "ibpb" option in
   :ref:`spectre_mitigation_control_command_line`).  This "ibpb" option
   has less performance cost than the "on" option, which leaves STIBP
   on all the time.

References on Spectre

Intel white papers:

.. _spec_ref1:

[1] `Intel analysis of speculative execution side channels <>`_.

.. _spec_ref2:

[2] `Bounds check bypass <>`_.

.. _spec_ref3:

[3] `Deep dive: Retpoline: A branch target injection mitigation <>`_.

.. _spec_ref4:

[4] `Deep Dive: Single Thread Indirect Branch Predictors <>`_.

AMD white papers:

.. _spec_ref5:

[5] `AMD64 technology indirect branch control extension <>`_.

.. _spec_ref6:

[6] `Software techniques for managing speculation on AMD processors <>`_.

ARM white papers:

.. _spec_ref7:

[7] `Cache speculation side-channels <>`_.

.. _spec_ref8:

[8] `Cache speculation issues update <>`_.

Google white paper:

.. _spec_ref9:

[9] `Retpoline: a software construct for preventing branch-target-injection <>`_.

MIPS white paper:

.. _spec_ref10:

[10] `MIPS: response on speculative execution and side channel vulnerabilities <>`_.

Academic papers:

.. _spec_ref11:

[11] `Spectre Attacks: Exploiting Speculative Execution <>`_.

.. _spec_ref12:

[12] `NetSpectre: Read Arbitrary Memory over Network <>`_.

.. _spec_ref13:

[13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <>`_.