726 lines · plain
1.. SPDX-License-Identifier: GPL-2.02 3Spectre Side Channels4=====================5 6Spectre is a class of side channel attacks that exploit branch prediction7and speculative execution on modern CPUs to read memory, possibly8bypassing access controls. Speculative execution side channel exploits9do 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 processors14-------------------15 16Speculative execution side channel methods affect a wide range of modern17high performance processors, since most modern high speed processors18use branch prediction and speculative execution.19 20The following CPUs are vulnerable:21 22 - Intel Core, Atom, Pentium, and Xeon processors23 24 - AMD Phenom, EPYC, and Zen processors25 26 - IBM POWER and zSeries processors27 28 - Higher end ARM processors29 30 - Apple CPUs31 32 - Higher end MIPS CPUs33 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 Spectre37vulnerability files in sysfs. See :ref:`spectre_sys_info`.38 39Related CVEs40------------41 42The following CVE entries describe Spectre variants:43 44 ============= ======================= ==========================45 CVE-2017-5753 Bounds check bypass Spectre variant 146 CVE-2017-5715 Branch target injection Spectre variant 247 CVE-2019-1125 Spectre v1 swapgs Spectre variant 1 (swapgs)48 ============= ======================= ==========================49 50Problem51-------52 53CPUs use speculative operations to improve performance. That may leave54traces of memory accesses or computations in the processor's caches,55buffers, and branch predictors. Malicious software may be able to56influence the speculative execution paths, and then use the side effects57of the speculative execution in the CPUs' caches and buffers to infer58privileged data touched during the speculative execution.59 60Spectre variant 1 attacks take advantage of speculative execution of61conditional branches, while Spectre variant 2 attacks use speculative62execution 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 advantage70of speculative execution that bypasses conditional branch instructions71used for memory access bounds check (e.g. checking if the index of an72array results in memory access within a valid range). This results in73memory accesses to invalid memory (with out-of-bound index) that are74done speculatively before validation checks resolve. Such speculative75memory accesses can leave side effects, creating side channels which76leak information to the attacker.77 78There are some extensions of Spectre variant 1 attacks for reading data79over the network, see :ref:`[12] <spec_ref12>`. However such attacks80are difficult, low bandwidth, fragile, and are considered low risk.81 82Note that, despite "Bounds Check Bypass" name, Spectre variant 1 is not83only about user-controlled array bounds checks. It can affect any84conditional checks. The kernel entry code interrupt, exception, and NMI85handlers all have conditional swapgs checks. Those may be problematic86in the context of Spectre v1, as kernel code can speculatively run with87a user GS.88 89Spectre variant 2 (Branch Target Injection)90-------------------------------------------91 92The branch target injection attack takes advantage of speculative93execution of indirect branches :ref:`[3] <spec_ref3>`. The indirect94branch predictors inside the processor used to guess the target of95indirect branches can be influenced by an attacker, causing gadget code96to be speculatively executed, thus exposing sensitive data touched by97the victim. The side effects left in the CPU's caches during speculative98execution can be measured to infer data values.99 100.. _poison_btb:101 102In Spectre variant 2 attacks, the attacker can steer speculative indirect103branches in the victim to gadget code by poisoning the branch target104buffer of a CPU used for predicting indirect branch addresses. Such105poisoning could be done by indirect branching into existing code,106with the address offset of the indirect branch under the attacker's107control. Since the branch prediction on impacted hardware does not108fully disambiguate branch address and uses the offset for prediction,109this could cause privileged code's indirect branch to jump to a gadget110code with the same offset.111 112The most useful gadgets take an attacker-controlled input parameter (such113as a register value) so that the memory read can be controlled. Gadgets114without input parameters might be possible, but the attacker would have115very little control over what memory can be read, reducing the risk of116the attack revealing useful data.117 118One other variant 2 attack vector is for the attacker to poison the119return stack buffer (RSB) :ref:`[13] <spec_ref13>` to cause speculative120subroutine return instruction execution to go to a gadget. An attacker's121imbalanced subroutine call instructions might "poison" entries in the122return stack buffer which are later consumed by a victim's subroutine123return instructions. This attack can be mitigated by flushing the return124stack buffer on context switch, or virtual machine (VM) exit.125 126On systems with simultaneous multi-threading (SMT), attacks are possible127from the sibling thread, as level 1 cache and branch target buffer128(BTB) may be shared between hardware threads in a CPU core. A malicious129program running on the sibling thread may influence its peer's BTB to130steer its indirect branch speculations to gadget code, and measure the131speculative execution's side effects left in level 1 cache to infer the132victim's data.133 134Yet another variant 2 attack vector is for the attacker to poison the135Branch History Buffer (BHB) to speculatively steer an indirect branch136to a specific Branch Target Buffer (BTB) entry, even if the entry isn't137associated with the source address of the indirect branch. Specifically,138the BHB might be shared across privilege levels even in the presence of139Enhanced IBRS.140 141Previously the only known real-world BHB attack vector was via unprivileged142eBPF. 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 or144use the BHB clearing sequence.145 146Attack scenarios147----------------148 149The following list of attack scenarios have been anticipated, but may150not cover all possible attack vectors.151 1521. A user process attacking the kernel153^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^154 155Spectre variant 1156~~~~~~~~~~~~~~~~~157 158 The attacker passes a parameter to the kernel via a register or159 via a known address in memory during a syscall. Such parameter may160 be used later by the kernel as an index to an array or to derive161 a pointer for a Spectre variant 1 attack. The index or pointer162 is invalid, but bound checks are bypassed in the code branch taken163 for speculative execution. This could cause privileged memory to be164 accessed and leaked.165 166 For kernel code that has been identified where data pointers could167 potentially be influenced for Spectre attacks, new "nospec" accessor168 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 the174 swapgs path for an interrupt or exception. If they initialize175 the GS register to a user-space value, if the swapgs is speculatively176 skipped, subsequent GS-related percpu accesses in the speculation177 window will be done with the attacker-controlled GS value. This178 could cause privileged memory to be accessed and leaked.179 180 For example:181 182 ::183 184 if (coming from user space)185 swapgs186 mov %gs:<percpu_offset>, %reg187 mov (%reg), %reg1188 189 When coming from user space, the CPU can speculatively skip the190 swapgs, and then do a speculative percpu load using the user GS191 value. So the user can speculatively force a read of any kernel192 value. If a gadget exists which uses the percpu value as an address193 in another load/store, then the contents of the kernel value may194 become visible via an L1 side channel attack.195 196 A similar attack exists when coming from kernel space. The CPU can197 speculatively do the swapgs, causing the user GS to get used for the198 rest of the speculative window.199 200Spectre variant 2201~~~~~~~~~~~~~~~~~202 203 A spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch204 target buffer (BTB) before issuing syscall to launch an attack.205 After entering the kernel, the kernel could use the poisoned branch206 target buffer on indirect jump and jump to gadget code in speculative207 execution.208 209 If an attacker tries to control the memory addresses leaked during210 speculative execution, he would also need to pass a parameter to the211 gadget, either through a register or a known address in memory. After212 the gadget has executed, he can measure the side effect.213 214 The kernel can protect itself against consuming poisoned branch215 target buffer entries by using return trampolines (also known as216 "retpoline") :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` for all217 indirect branches. Return trampolines trap speculative execution paths218 to prevent jumping to gadget code during speculative execution.219 x86 CPUs with Enhanced Indirect Branch Restricted Speculation220 (Enhanced IBRS) available in hardware should use the feature to221 mitigate Spectre variant 2 instead of retpoline. Enhanced IBRS is222 more efficient than retpoline.223 224 There may be gadget code in firmware which could be exploited with225 Spectre variant 2 attack by a rogue user process. To mitigate such226 attacks on x86, Indirect Branch Restricted Speculation (IBRS) feature227 is turned on before the kernel invokes any firmware code.228 2292. A user process attacking another user process230^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^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 the234 sibling hyperthread sharing a physical processor core on simultaneous235 multi-threading (SMT) system.236 237 Spectre variant 1 attacks generally require passing parameters238 between the processes, which needs a data passing relationship, such239 as remote procedure calls (RPC). Those parameters are used in gadget240 code to derive invalid data pointers accessing privileged memory in241 the attacked process.242 243 Spectre variant 2 attacks can be launched from a rogue process by244 :ref:`poisoning <poison_btb>` the branch target buffer. This can245 influence the indirect branch targets for a victim process that either246 runs later on the same hardware thread, or running concurrently on247 a sibling hardware thread sharing the same physical core.248 249 A user process can protect itself against Spectre variant 2 attacks250 by using the prctl() syscall to disable indirect branch speculation251 for itself. An administrator can also cordon off an unsafe process252 from polluting the branch target buffer by disabling the process's253 indirect branch speculation. This comes with a performance cost254 from not using indirect branch speculation and clearing the branch255 target buffer. When SMT is enabled on x86, for a process that has256 indirect branch speculation disabled, Single Threaded Indirect Branch257 Predictors (STIBP) :ref:`[4] <spec_ref4>` are turned on to prevent the258 sibling thread from controlling branch target buffer. In addition,259 the Indirect Branch Prediction Barrier (IBPB) is issued to clear the260 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 branch264 prediction when the return stack buffer underflows while switching to265 a deeper call stack. Any poisoned entries in the return stack buffer266 left by the previous process will also be cleared.267 268 User programs should use address space randomization to make attacks269 more difficult (Set /proc/sys/kernel/randomize_va_space = 1 or 2).270 2713. A virtualized guest attacking the host272^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^273 274 The attack mechanism is similar to how user processes attack the275 kernel. The kernel is entered via hyper-calls or other virtualization276 exit paths.277 278 For Spectre variant 1 attacks, rogue guests can pass parameters279 (e.g. in registers) via hyper-calls to derive invalid pointers to280 speculate into privileged memory after entering the kernel. For places281 where such kernel code has been identified, nospec accessor macros282 are used to stop speculative memory access.283 284 For Spectre variant 2 attacks, rogue guests can :ref:`poison285 <poison_btb>` the branch target buffer or return stack buffer, causing286 the kernel to jump to gadget code in the speculative execution paths.287 288 To mitigate variant 2, the host kernel can use return trampolines289 for indirect branches to bypass the poisoned branch target buffer,290 and flushing the return stack buffer on VM exit. This prevents rogue291 guests from affecting indirect branching in the host kernel.292 293 To protect host processes from rogue guests, host processes can have294 indirect branch speculation disabled via prctl(). The branch target295 buffer is cleared before context switching to such processes.296 2974. A virtualized guest attacking other guest298^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^299 300 A rogue guest may attack another guest to get data accessible by the301 other guest.302 303 Spectre variant 1 attacks are possible if parameters can be passed304 between guests. This may be done via mechanisms such as shared memory305 or message passing. Such parameters could be used to derive data306 pointers to privileged data in guest. The privileged data could be307 accessed by gadget code in the victim's speculation paths.308 309 Spectre variant 2 attacks can be launched from a rogue guest by310 :ref:`poisoning <poison_btb>` the branch target buffer or the return311 stack buffer. Such poisoned entries could be used to influence312 speculation execution paths in the victim guest.313 314 Linux kernel mitigates attacks to other guests running in the same315 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 guest319 in the sibling hyperthread can be mitigated by the administrator,320 by turning off the unsafe guest's indirect branch speculation via321 prctl(). A guest can also protect itself by turning on microcode322 based mitigations (such as IBPB or STIBP on x86) within the guest.323 324.. _spectre_sys_info:325 326Spectre system information327--------------------------328 329The Linux kernel provides a sysfs interface to enumerate the current330mitigation status of the system for Spectre: whether the system is331vulnerable, and which mitigations are active.332 333The sysfs file showing Spectre variant 1 mitigation status is:334 335 /sys/devices/system/cpu/vulnerabilities/spectre_v1336 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 has345 protection in the kernel on a case by case base with explicit346 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 explicit349 pointer sanitation, usercopy LFENCE barriers, and swapgs LFENCE350 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 Spectre354variant 1 are covered.355 356The spectre_v2 kernel file reports if the kernel has been compiled with357retpoline mitigation or if the CPU has hardware mitigation, and if the358CPU has support for additional process-specific mitigation.359 360This file also reports CPU features enabled by microcode to mitigate361attack between user processes:362 3631. Indirect Branch Prediction Barrier (IBPB) to add additional364 isolation between processes of different users.3652. Single Thread Indirect Branch Predictors (STIBP) to add additional366 isolation between CPU threads running on the same core.367 368These CPU features may impact performance when used and can be enabled369per 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_v2374 375The possible values in this file are:376 377 - Kernel status:378 379 ======================================== =================================380 'Not affected' The processor is not vulnerable381 'Mitigation: None' Vulnerable, no mitigation382 'Mitigation: Retpolines' Use Retpoline thunks383 'Mitigation: LFENCE' Use LFENCE instructions384 'Mitigation: Enhanced IBRS' Hardware-focused mitigation385 'Mitigation: Enhanced IBRS + Retpolines' Hardware-focused + Retpolines386 'Mitigation: Enhanced IBRS + LFENCE' Hardware-focused + LFENCE387 ======================================== =================================388 389 - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is390 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 firmware394 ========== =============================================================395 396 - Indirect branch prediction barrier (IBPB) status for protection between397 processes of different users. This feature can be controlled through398 prctl() per process, or through kernel command line options. This is399 an x86 only feature. For more details see below.400 401 =================== ========================================================402 'IBPB: disabled' IBPB unused403 'IBPB: always-on' Use IBPB on all tasks404 'IBPB: conditional' Use IBPB on SECCOMP or indirect branch restricted tasks405 =================== ========================================================406 407 - Single threaded indirect branch prediction (STIBP) status for protection408 between different hyper threads. This feature can be controlled through409 prctl per process, or through kernel command line options. This is x86410 only feature. For more details see below.411 412 ==================== ========================================================413 'STIBP: disabled' STIBP unused414 'STIBP: forced' Use STIBP on all tasks415 'STIBP: conditional' Use STIBP on SECCOMP or indirect branch restricted tasks416 ==================== ========================================================417 418 - Return stack buffer (RSB) protection status:419 420 ============= ===========================================421 'RSB filling' Protection of RSB on context switch enabled422 ============= ===========================================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 enabled428 'PBRSB-eIBRS: Vulnerable' CPU is vulnerable429 'PBRSB-eIBRS: Not affected' CPU is not affected by PBRSB430 =========================== =======================================================431 432 - Branch History Injection (BHI) protection status:433 434.. list-table::435 436 * - BHI: Not affected437 - System is not affected438 * - BHI: Retpoline439 - System is protected by retpoline440 * - BHI: BHI_DIS_S441 - System is protected by BHI_DIS_S442 * - BHI: SW loop, KVM SW loop443 - System is protected by software clearing sequence444 * - BHI: Vulnerable445 - System is vulnerable to BHI446 * - BHI: Vulnerable, KVM: SW loop447 - System is vulnerable; KVM is protected by software clearing sequence448 449Full mitigation might require a microcode update from the CPU450vendor. When the necessary microcode is not available, the kernel will451report vulnerability.452 453Turning on mitigation for Spectre variant 1 and Spectre variant 2454-----------------------------------------------------------------455 4561. Kernel mitigation457^^^^^^^^^^^^^^^^^^^^458 459Spectre variant 1460~~~~~~~~~~~~~~~~~461 462 For the Spectre variant 1, vulnerable kernel code (as determined463 by code audit or scanning tools) is annotated on a case by case464 basis to use nospec accessor macros for bounds clipping :ref:`[2]465 <spec_ref2>` to avoid any usable disclosure gadgets. However, it may466 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 the470 barrier_nospec() macro.471 472 For the swapgs variant of Spectre variant 1, LFENCE barriers are473 added to interrupt, exception and NMI entry where needed. These474 barriers are done by the FENCE_SWAPGS_KERNEL_ENTRY and475 FENCE_SWAPGS_USER_ENTRY macros.476 477Spectre variant 2478~~~~~~~~~~~~~~~~~479 480 For Spectre variant 2 mitigation, the compiler turns indirect calls or481 jumps in the kernel into equivalent return trampolines (retpolines)482 :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` to go to the target483 addresses. Speculative execution paths under retpolines are trapped484 in an infinite loop to prevent any speculative execution jumping to485 a gadget.486 487 To turn on retpoline mitigation on a vulnerable CPU, the kernel488 needs to be compiled with a gcc compiler that supports the489 -mindirect-branch=thunk-extern -mindirect-branch-register options.490 If the kernel is compiled with a Clang compiler, the compiler needs491 to support -mretpoline-external-thunk option. The kernel config492 CONFIG_MITIGATION_RETPOLINE needs to be turned on, and the CPU needs493 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. IBRS499 or enhanced IBRS on x86), retpoline is automatically disabled at run time.500 501 Systems which support enhanced IBRS (eIBRS) enable IBRS protection once at502 boot, by setting the IBRS bit, and they're automatically protected against503 some Spectre v2 variant attacks. The BHB can still influence the choice of504 indirect branch predictor entry, and although branch predictor entries are505 isolated between modes when eIBRS is enabled, the BHB itself is not isolated506 between modes. Systems which support BHI_DIS_S will set it to protect against507 BHI attacks.508 509 On Intel's enhanced IBRS systems, this includes cross-thread branch target510 injections on SMT systems (STIBP). In other words, Intel eIBRS enables511 STIBP, too.512 513 AMD Automatic IBRS does not protect userspace, and Legacy IBRS systems clear514 the IBRS bit on exit to userspace, therefore both explicitly enable STIBP.515 516 The retpoline mitigation is turned on by default on vulnerable517 CPUs. It can be forced on or off by the administrator518 via the kernel command line and sysfs control files. See519 :ref:`spectre_mitigation_control_command_line`.520 521 On x86, indirect branch restricted speculation is turned on by default522 before invoking any firmware code to prevent Spectre variant 2 exploits523 using the firmware.524 525 Using kernel address space randomization (CONFIG_RANDOMIZE_BASE=y526 and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes527 attacks on the kernel generally more difficult.528 5292. User program mitigation530^^^^^^^^^^^^^^^^^^^^^^^^^^531 532 User programs can mitigate Spectre variant 1 using LFENCE or "bounds533 clipping". For more details see :ref:`[2] <spec_ref2>`.534 535 For Spectre variant 2 mitigation, individual user programs536 can be compiled with return trampolines for indirect branches.537 This protects them from consuming poisoned entries in the branch538 target buffer left by malicious software.539 540 On legacy IBRS systems, at return to userspace, implicit STIBP is disabled541 because the kernel clears the IBRS bit. In this case, the userspace programs542 can disable indirect branch speculation via prctl() (See543 :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).544 On x86, this will turn on STIBP to guard against attacks from the545 sibling thread when the user program is running, and use IBPB to546 flush the branch target buffer when switching to/from the program.547 548 Restricting indirect branch speculation on a user program will549 also prevent the program from launching a variant 2 attack550 on x86. Administrators can change that behavior via the kernel551 command line and sysfs control files.552 See :ref:`spectre_mitigation_control_command_line`.553 554 Programs that disable their indirect branch speculation will have555 more overhead and run slower.556 557 User programs should use address space randomization558 (/proc/sys/kernel/randomize_va_space = 1 or 2) to make attacks more559 difficult.560 5613. VM mitigation562^^^^^^^^^^^^^^^^563 564 Within the kernel, Spectre variant 1 attacks from rogue guests are565 mitigated on a case by case basis in VM exit paths. Vulnerable code566 uses nospec accessor macros for "bounds clipping", to avoid any567 usable disclosure gadgets. However, this may not cover all variant568 1 attack vectors.569 570 For Spectre variant 2 attacks from rogue guests to the kernel, the571 Linux kernel uses retpoline or Enhanced IBRS to prevent consumption of572 poisoned entries in branch target buffer left by rogue guests. It also573 flushes the return stack buffer on every VM exit to prevent a return574 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 switching579 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 is584 in use, an untrusted guest running in the sibling thread can have585 its indirect branch speculation disabled by administrator via prctl().586 587 The kernel also allows guests to use any microcode based mitigation588 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 line593---------------------------------------------594 595In general the kernel selects reasonable default mitigations for the596current CPU.597 598Spectre default mitigations can be disabled or changed at the kernel599command line with the following options:600 601 - nospectre_v1602 - nospectre_v2603 - spectre_v2={option}604 - spectre_v2_user={option}605 - spectre_bhi={option}606 607For more details on the available options, refer to Documentation/admin-guide/kernel-parameters.txt608 609Mitigation selection guide610--------------------------611 6121. Trusted userspace613^^^^^^^^^^^^^^^^^^^^614 615 If all userspace applications are from trusted sources and do not616 execute externally supplied untrusted code, then the mitigations can617 be disabled.618 6192. Protect sensitive programs620^^^^^^^^^^^^^^^^^^^^^^^^^^^^^621 622 For security-sensitive programs that have secrets (e.g. crypto623 keys), protection against Spectre variant 2 can be put in place by624 disabling indirect branch speculation when the program is running625 (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).626 6273. Sandbox untrusted programs628^^^^^^^^^^^^^^^^^^^^^^^^^^^^^629 630 Untrusted programs that could be a source of attacks can be cordoned631 off by disabling their indirect branch speculation when they are run632 (See :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).633 This prevents untrusted programs from polluting the branch target634 buffer. This behavior can be changed via the kernel command line635 and sysfs control files. See636 :ref:`spectre_mitigation_control_command_line`.637 6383. High security mode639^^^^^^^^^^^^^^^^^^^^^640 641 All Spectre variant 2 mitigations can be forced on642 at boot time for all programs (See the "on" option in643 :ref:`spectre_mitigation_control_command_line`). This will add644 overhead as indirect branch speculations for all programs will be645 restricted.646 647 On x86, branch target buffer will be flushed with IBPB when switching648 to a new program. STIBP is left on all the time to protect programs649 against variant 2 attacks originating from programs running on650 sibling threads.651 652 Alternatively, STIBP can be used only when running programs653 whose indirect branch speculation is explicitly disabled,654 while IBPB is still used all the time when switching to a new655 program to clear the branch target buffer (See "ibpb" option in656 :ref:`spectre_mitigation_control_command_line`). This "ibpb" option657 has less performance cost than the "on" option, which leaves STIBP658 on all the time.659 660References on Spectre661---------------------662 663Intel white papers:664 665.. _spec_ref1:666 667[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>`_.668 669.. _spec_ref2:670 671[2] `Bounds check bypass <https://software.intel.com/security-software-guidance/software-guidance/bounds-check-bypass>`_.672 673.. _spec_ref3:674 675[3] `Deep dive: Retpoline: A branch target injection mitigation <https://software.intel.com/security-software-guidance/insights/deep-dive-retpoline-branch-target-injection-mitigation>`_.676 677.. _spec_ref4:678 679[4] `Deep Dive: Single Thread Indirect Branch Predictors <https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors>`_.680 681AMD white papers:682 683.. _spec_ref5:684 685[5] `AMD64 technology indirect branch control extension <https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf>`_.686 687.. _spec_ref6:688 689[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf>`_.690 691ARM white papers:692 693.. _spec_ref7:694 695[7] `Cache speculation side-channels <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/download-the-whitepaper>`_.696 697.. _spec_ref8:698 699[8] `Cache speculation issues update <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/latest-updates/cache-speculation-issues-update>`_.700 701Google white paper:702 703.. _spec_ref9:704 705[9] `Retpoline: a software construct for preventing branch-target-injection <https://support.google.com/faqs/answer/7625886>`_.706 707MIPS white paper:708 709.. _spec_ref10:710 711[10] `MIPS: response on speculative execution and side channel vulnerabilities <https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/>`_.712 713Academic papers:714 715.. _spec_ref11:716 717[11] `Spectre Attacks: Exploiting Speculative Execution <https://spectreattack.com/spectre.pdf>`_.718 719.. _spec_ref12:720 721[12] `NetSpectre: Read Arbitrary Memory over Network <https://arxiv.org/abs/1807.10535>`_.722 723.. _spec_ref13:724 725[13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://www.usenix.org/system/files/conference/woot18/woot18-paper-koruyeh.pdf>`_.726