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