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