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