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