Tim, On Thu, 6 Jun 2019, Tim Chen wrote: > Here's a revised version of the spectre documentation. thanks for the follow up! > +++ b/Documentation/admin-guide/hw-vuln/spectre.rst > @@ -0,0 +1,619 @@ Please add a SPDX license identifier > +Spectre side channels > +===================== > + > +Spectre is a class of side channel attacks that exploit branch prediction > +and speculative execution on modern CPUs to read memory, possibly > +bypassing access controls. Speculative execution side channel exploits > +do not modify memory but attempt to infer privileged data in the memory. > + > +This document covers Spectre variant 1 and Spectre variant 2. > + > +Affected processors > +------------------- > + > +Speculative execution side channel methods affect a wide range of modern > +high performance processors, since most modern high speed processors > +use branch predictions and speculative executions. branch prediction and speculative execution > + > +The following CPUs are vulnerable: > + > + - Intel Core, Atom, Pentium, and Xeon processors > + - AMD Phenom, EPYC, and Zen processors > + - IBM POWER and zSeries processors > + - Higher end ARM processors > + - Apple CPUs > + - Higher end MIPS CPUs > + - Likely most other high performance CPUs. Contact your CPU vendor for details. Please use line breaks. They work nicely in lists. > + > +Whether a processor is affected or not can be read out from the Spectre > +vulnerability files in sysfs. See :ref:`spectre_sys_info`. > + > +Related CVEs > +------------ > + > +The following CVE entries describe Spectre variants: > + > + ============= ======================= ================= > + CVE-2017-5753 Bounds check bypass Spectre variant 1 > + CVE-2017-5715 Branch target injection Spectre variant 2 > + ============= ======================= ================= > + > +Problem > +------- > + > +CPUs use speculative operations to improve performance. That may leave > +traces of memory accesses or computations in the processor's caches, > +buffers, and branch predictors. Malicious software may be able to > +influence the speculative execution paths, and then use the side effects > +of the speculative execution in the CPUs caches and buffers to infer > +privileged data touched during the speculative execution. > + > +Spectre variant 1 attacks take advantage of speculative execution of > +conditional branches, while Spectre variant 2 attacks use speculative > +execution of indirect branches to leak privileged memory. See [1] [5] > +[7] [10] [11]. > + > +Spectre variant 1 (Bounds Check Bypass) > +--------------------------------------- > + > +The bounds check bypass attack [2] takes advantage of speculative > +execution that bypass conditional branch instructions used for memory > +access bounds check (e.g. checking if the index of an array results in > +memory access within a valid range). This results in memory accesses to > +invalid memory (say with out-of-bound index) that are done speculatively s/say// > +before validation checks resolve. Such speculative memory accesses can > +leave side effects, creating side channels which leak information to > +the attacker. > + > +There are some extensions of Spectre variant 1 attacks for reading > +data over the network, see [12]. However such attacks are difficult, > +low bandwidth, fragile, and are considered low risk. > + > +Spectre variant 2 (Branch Target Injection) > +------------------------------------------- > + > +The branch target injection attack takes advantage of speculative > +execution of indirect branches [3]. The indirect branch predictors > +inside the processor used to guess the target of indirect branches can > +be influenced by an attacker, causing gadget code to be speculatively > +executed, thus exposing sensitive data touched by the victim. The side > +effects left in the CPU's caches during speculative execution can be > +measured to infer data values. > + > +.. _poison_btb: > + > +In Spectre variant 2 attacks, the attacker can steer speculative indirect > +branches in the victim to gadget code by poisoning the branch target > +buffer of a CPU used for predicting indirect branch addresses. Such > +poisoning could be done by indirect branching into existing code, with the > +address offset of the indirect branch under the attacker's control. Since > +the branch prediction hardware does not fully disambiguate branch address > +and uses the offset for prediction, this could cause privileged code's > +indirect branch to jump to a gadget code with the same offset. > + > +The most useful gadgets take an attacker-controlled input parameter (such > +as a register value) so that the memory read can be controlled. Gadgets > +without input parameters might be possible, but the attacker would have > +very little control over what memory can be read, reducing the risk of > +the attack revealing useful data. > + > +One other variant 2 attack vector is for the attacker to poison the > +return stack buffer (RSB) [13] to cause speculative RET execution to go > +to an gadget. An attacker's imbalanced CALL instructions might "poison" > +entries in the return stack buffer which are later consumed by a victim's > +RET instruction. This attack can be mitigated by flushing the return > +stack buffer on context switch, or VM exit. This should mention that SMT sibling threads can be affected because L1 and BTB can be shared resources. > +Attack scenarios > +---------------- > + > +The following list of attack scenarios have been anticipated, but may > +not cover all possible attack vectors. > + > +1. A user process attacking the kernel > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > + The attacker passes a parameter to the kernel via a register or via a > + known address in memory during a syscall. Such parameter may be used > + later by the kernel as an index to an array or to derive a pointer > + for Spectre variant 1 attack. The index or pointer is invalid, but ... for a Spectre ... > +2. A user process attacking another user process > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > + A malicious user process can try to attack another user process, > + either via a context switch on the same hardware thread, or from the > + sibling hyperthread sharing a physical processor core on simultaneous > + multi-threading (SMT) system. > + > + Spectre variant 1 attacks generally require passing parameters between > + the processes, which needs a data passing relationship, such as remote > + procedure calls (RPC). Those parameters are used in gadget code to > + derive invalid data pointers accessing privileged memory. priviledged memory in the attacked process. > + Spectre variant 2 attacks can be launched by a rogue process by > + :ref:`poisoning <poison_btb>` the branch target buffer. This can > + influence the indirect branch targets for a victim process that either > + runs later on the same hardware thread, or running concurrently on > + a sibling hardware thread running on the same physical core. s/thread running on/thread sharing/ > + On x86, a user process can protect itself against Spectre variant 2 > + attacks by using prctl syscall to disable indirect branch speculation s/using prctl syscall/using the prctl() syscall/ > + for itself. An administrator can also cordon off an unsafe process > + from polluting the branch target buffer by disabling the process's > + indirect branch speculation. This comes with a performance cost from > + disabling indirect branch speculation and clearing the branch target > + buffer. On SMT CPU, for a process that has indirect branch speculation s/On SMT CPU/When SMT is enabled > + disabled, Single Threaded Indirect Branch Predictors (STIBP) [4] > + is turned on to prevent the sibling thread from controlling branch s/is/are/ Predictors are clearly plural > + target buffer. In addition, Indirect Branch Prediction Barrier (IBPB) In addition, the Indirect .. > + is issued to clear the branch target buffer when context switching > + to and from such process. > + > + On x86, the return stack buffer is stuffed on context switch. > + This prevents the branch target buffer from being used for branch > + prediction when the return stack buffer underflow while switching to underflows > + a deeper call stack. Any poisoned entries in the return stack buffer > + left by the previous process will also be cleared. > + > + User programs should use address space randomization to make attacks > + more difficult (Set /proc/sys/kernel/randomize_va_space = 1 or 2). > + > +3. A virtualized guest attacking the host > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > + The attack mechanism is similar to how user processes attack the > + kernel. The kernel is entered via hyper calls or other virtualization Please use the 'hyper-call' notation consistently. > + exit paths. > + > + For Spectre variant 1 attack, rogue guests can pass parameters (e.g. in either: For a Spectre variant 1 attack, or: For Spectre variant 1 attacks, > + registers) via hyper-calls to derive invalid pointers to speculate > + into privileged memory after entering the kernel. For places where > + such kernel code are identified, nospec accessor macros are used to s/are/has been identified/ > + stop speculative memory access. > + > + For Spectre variant 2 attack, rogue guests can :ref:`poison See above. > + <poison_btb>` the branch target buffer or return stack buffer, causing > + the kernel to jump to gadget code in the speculative execution paths. > + > + To mitigate variant 2, the host kernel can use return trampoline trampolines > + for indirect branches to bypass poisoned branch target buffer, and to bypass the > + flushes return stack buffer on VM exit. This prevents rogue guest s/and flushes return/and flushing the return/ > + from affecting indirect branching in host kernel. > + > + To protect host processes from rogue guests, host processes can have > + indirect branch speculation disabled via prctl. The branch target prctl() > + buffer is cleared before context switching to such processes. > + > +4. A virtualized guest attacking other guest > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > + A rogue guest may attack another guest to get data accessible by the > + other guest. > + > + Spectre variant 1 attack is possible if parameters can be passed > + between guests. This may be done via mechanisms such as shared memory > + or message passing. Such parameters could be used to derive data > + pointers to privileged data in guest. The privileged data could be > + accessed by gadget code in the victim's speculation paths. > + > + Spectre variant 2 attack can be launched from a rogue guest by > + :ref:`poisoning <poison_btb>` the branch target buffer or return stack > + buffer. Such poisoned entries could be used to influence speculation > + execution paths in the victim guest. Linux kernel mitigates such > + attacks by flushing the return stack buffer on VM exit and also clears > + the branch target buffer before switching to a new guest. This needs to explain that this is not preventing SMT sibling attacks. > +Turning on mitigation for Spectre variant 1 and Spectre variant 2 > +----------------------------------------------------------------- > + > +1. Kernel mitigation > +^^^^^^^^^^^^^^^^^^^^ > + > + For Spectre variant 1, vulnerable kernel codes (as determined by code For the Spectre .. s/codes/code/ > + audit or scanning tools) are annotated on a case by case basis to use > + nospec accessor macros for bounds clipping [2] to avoid any usable > + disclosure gadgets. However, it may not cover all attack vectors for > + Spectre variant 1. > + > + For Spectre variant 2 mitigation, the compiler turns indirect calls or > + jumps in the kernel into an equivalent return trampolines (retpoline) s/an// > + [3] [9] to go to the target addresses. Speculative execution paths > + under retpolines are trapped in an infinite loop to prevent any > + speculative execution jumping to a gadget. > + > + To turn on retpoline mitigation on a vulnerable CPU, the kernel > + needs to be compiled with a gcc compiler that supports the > + -mindirect-branch=thunk-extern -mindirect-branch-register options. > + If the kernel is compiled with a clangs compiler, the compiler needs s/clangs/Clang/ > +2. User program mitigation > +^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > + User programs can mitigate Spectre variant 1 using LFENCE or "bounds > + clipping". For more details see [2]. > + > + For Spectre variant 2 mitigation, individual user programs > + can be compiled with return trampolines for indirect branches. > + This protects them from consuming poisoned entries in Branch Target in the Branch... > + Buffer left by malicious software. Alternatively, the programs > + can disable their indirect branch speculation via prctl (See prctl() > + :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`) > + On x86, this will turn on STIBP to guard against attacks from the > + sibling thread when the user program is running, and use IBPB to > + flush the branch target buffer when switching to/from the program. > +3. VM mitigation > +^^^^^^^^^^^^^^^^ > + > + Within the kernel, Spectre variant 1 attacks from rogue guests > + are mitigated on a case by case basis in VM exit paths. Vulnerable > + codes use nospec accessor macros for "bounds clipping", to avoid any code uses > + usable disclosure gadgets. However, this may not cover all variant > + 1 attack vectors. > + > + For Spectre variant 2 attacks from rogue guests to the kernel, the > + Linux kernel uses retpoline to prevent consumption of poisoned entries uses retpoline or Enhanced IBRS > + in branch target buffer left by rogue guests. It also flushes the > + return stack buffer on every VM exit to prevent return stack buffer prevent a return ... > + underflow so poisoned branch target buffer could be used, or attacker > + guests leaving poisoned entries in the return stack buffer. > + > + To mitigate guest-to-guest attacks, the branch target buffer is > + sanitized by flushing before switching to a new guest on a CPU. > + > + These mitigations are turned on by default on vulnerable CPUs. > + > + The kernel also allows guests to use any microcode based mitigation > + they chose to use (such as IBPB or STIBP on x86). > + > +.. _mitigation_control_command_line: ... Aside of the few nitpicks this is a very well done document! Thanks, tglx
