| From foo@baz Wed Mar 9 04:10:24 PM CET 2022 |
| From: Tim Chen <tim.c.chen@linux.intel.com> |
| Date: Thu, 20 Jun 2019 16:10:50 -0700 |
| Subject: Documentation: Add section about CPU vulnerabilities for Spectre |
| |
| From: Tim Chen <tim.c.chen@linux.intel.com> |
| |
| commit 6e88559470f581741bcd0f2794f9054814ac9740 upstream. |
| |
| Add documentation for Spectre vulnerability and the mitigation mechanisms: |
| |
| - Explain the problem and risks |
| - Document the mitigation mechanisms |
| - Document the command line controls |
| - Document the sysfs files |
| |
| Co-developed-by: Andi Kleen <ak@linux.intel.com> |
| Signed-off-by: Andi Kleen <ak@linux.intel.com> |
| Co-developed-by: Tim Chen <tim.c.chen@linux.intel.com> |
| Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com> |
| Reviewed-by: Randy Dunlap <rdunlap@infradead.org> |
| Reviewed-by: Thomas Gleixner <tglx@linutronix.de> |
| Cc: stable@vger.kernel.org |
| Signed-off-by: Jonathan Corbet <corbet@lwn.net> |
| [bwh: Backported to 4.9: |
| - Drop chnages in spec_ctrl.rst, which is a plain-text document here |
| - Adjust filenames and references to spec_ctrl.rst] |
| Signed-off-by: Ben Hutchings <ben@decadent.org.uk> |
| Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| --- |
| Documentation/hw-vuln/index.rst | 1 |
| Documentation/hw-vuln/spectre.rst | 697 ++++++++++++++++++++++++++++++++++++++ |
| 2 files changed, 698 insertions(+) |
| create mode 100644 Documentation/hw-vuln/spectre.rst |
| |
| --- a/Documentation/hw-vuln/index.rst |
| +++ b/Documentation/hw-vuln/index.rst |
| @@ -9,6 +9,7 @@ are configurable at compile, boot or run |
| .. toctree:: |
| :maxdepth: 1 |
| |
| + spectre |
| l1tf |
| mds |
| tsx_async_abort |
| --- /dev/null |
| +++ b/Documentation/hw-vuln/spectre.rst |
| @@ -0,0 +1,697 @@ |
| +.. SPDX-License-Identifier: GPL-2.0 |
| + |
| +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 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. |
| + |
| +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 :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[7] <spec_ref7>` |
| +:ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`. |
| + |
| +Spectre variant 1 (Bounds Check Bypass) |
| +--------------------------------------- |
| + |
| +The bounds check bypass attack :ref:`[2] <spec_ref2>` takes advantage |
| +of speculative execution that bypasses 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 (with out-of-bound index) that are |
| +done speculatively 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 :ref:`[12] <spec_ref12>`. 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 :ref:`[3] <spec_ref3>`. 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 on impacted 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) :ref:`[13] <spec_ref13>` to cause speculative |
| +subroutine return instruction execution to go to a gadget. An attacker's |
| +imbalanced subroutine call instructions might "poison" entries in the |
| +return stack buffer which are later consumed by a victim's subroutine |
| +return instructions. This attack can be mitigated by flushing the return |
| +stack buffer on context switch, or virtual machine (VM) exit. |
| + |
| +On systems with simultaneous multi-threading (SMT), attacks are possible |
| +from the sibling thread, as level 1 cache and branch target buffer |
| +(BTB) may be shared between hardware threads in a CPU core. A malicious |
| +program running on the sibling thread may influence its peer's BTB to |
| +steer its indirect branch speculations to gadget code, and measure the |
| +speculative execution's side effects left in level 1 cache to infer the |
| +victim's data. |
| + |
| +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 a Spectre variant 1 attack. The index or pointer |
| + is invalid, but bound checks are bypassed in the code branch taken |
| + for speculative execution. This could cause privileged memory to be |
| + accessed and leaked. |
| + |
| + For kernel code that has been identified where data pointers could |
| + potentially be influenced for Spectre attacks, new "nospec" accessor |
| + macros are used to prevent speculative loading of data. |
| + |
| + Spectre variant 2 attacker can :ref:`poison <poison_btb>` the branch |
| + target buffer (BTB) before issuing syscall to launch an attack. |
| + After entering the kernel, the kernel could use the poisoned branch |
| + target buffer on indirect jump and jump to gadget code in speculative |
| + execution. |
| + |
| + If an attacker tries to control the memory addresses leaked during |
| + speculative execution, he would also need to pass a parameter to the |
| + gadget, either through a register or a known address in memory. After |
| + the gadget has executed, he can measure the side effect. |
| + |
| + The kernel can protect itself against consuming poisoned branch |
| + target buffer entries by using return trampolines (also known as |
| + "retpoline") :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` for all |
| + indirect branches. Return trampolines trap speculative execution paths |
| + to prevent jumping to gadget code during speculative execution. |
| + x86 CPUs with Enhanced Indirect Branch Restricted Speculation |
| + (Enhanced IBRS) available in hardware should use the feature to |
| + mitigate Spectre variant 2 instead of retpoline. Enhanced IBRS is |
| + more efficient than retpoline. |
| + |
| + There may be gadget code in firmware which could be exploited with |
| + Spectre variant 2 attack by a rogue user process. To mitigate such |
| + attacks on x86, Indirect Branch Restricted Speculation (IBRS) feature |
| + is turned on before the kernel invokes any firmware code. |
| + |
| +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 in |
| + the attacked process. |
| + |
| + Spectre variant 2 attacks can be launched from 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 sharing the same physical core. |
| + |
| + A user process can protect itself against Spectre variant 2 attacks |
| + by using the prctl() syscall to disable indirect branch speculation |
| + 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 not using indirect branch speculation and clearing the branch |
| + target buffer. When SMT is enabled on x86, for a process that has |
| + indirect branch speculation disabled, Single Threaded Indirect Branch |
| + Predictors (STIBP) :ref:`[4] <spec_ref4>` are turned on to prevent the |
| + sibling thread from controlling branch target buffer. In addition, |
| + the Indirect Branch Prediction Barrier (IBPB) 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 underflows while switching to |
| + 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 |
| + exit paths. |
| + |
| + For Spectre variant 1 attacks, rogue guests can pass parameters |
| + (e.g. in registers) via hyper-calls to derive invalid pointers to |
| + speculate into privileged memory after entering the kernel. For places |
| + where such kernel code has been identified, nospec accessor macros |
| + are used to stop speculative memory access. |
| + |
| + For Spectre variant 2 attacks, rogue guests can :ref:`poison |
| + <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 trampolines |
| + for indirect branches to bypass the poisoned branch target buffer, |
| + and flushing the return stack buffer on VM exit. This prevents rogue |
| + guests from affecting indirect branching in the host kernel. |
| + |
| + To protect host processes from rogue guests, host processes can have |
| + indirect branch speculation disabled via prctl(). The branch target |
| + 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 attacks are 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 attacks can be launched from a rogue guest by |
| + :ref:`poisoning <poison_btb>` the branch target buffer or the return |
| + stack buffer. Such poisoned entries could be used to influence |
| + speculation execution paths in the victim guest. |
| + |
| + Linux kernel mitigates attacks to other guests running in the same |
| + CPU hardware thread by flushing the return stack buffer on VM exit, |
| + and clearing the branch target buffer before switching to a new guest. |
| + |
| + If SMT is used, Spectre variant 2 attacks from an untrusted guest |
| + in the sibling hyperthread can be mitigated by the administrator, |
| + by turning off the unsafe guest's indirect branch speculation via |
| + prctl(). A guest can also protect itself by turning on microcode |
| + based mitigations (such as IBPB or STIBP on x86) within the guest. |
| + |
| +.. _spectre_sys_info: |
| + |
| +Spectre system information |
| +-------------------------- |
| + |
| +The Linux kernel provides a sysfs interface to enumerate the current |
| +mitigation status of the system for Spectre: whether the system is |
| +vulnerable, and which mitigations are active. |
| + |
| +The sysfs file showing Spectre variant 1 mitigation status is: |
| + |
| + /sys/devices/system/cpu/vulnerabilities/spectre_v1 |
| + |
| +The possible values in this file are: |
| + |
| + ======================================= ================================= |
| + 'Mitigation: __user pointer sanitation' Protection in kernel on a case by |
| + case base with explicit pointer |
| + sanitation. |
| + ======================================= ================================= |
| + |
| +However, the protections are put in place on a case by case basis, |
| +and there is no guarantee that all possible attack vectors for Spectre |
| +variant 1 are covered. |
| + |
| +The spectre_v2 kernel file reports if the kernel has been compiled with |
| +retpoline mitigation or if the CPU has hardware mitigation, and if the |
| +CPU has support for additional process-specific mitigation. |
| + |
| +This file also reports CPU features enabled by microcode to mitigate |
| +attack between user processes: |
| + |
| +1. Indirect Branch Prediction Barrier (IBPB) to add additional |
| + isolation between processes of different users. |
| +2. Single Thread Indirect Branch Predictors (STIBP) to add additional |
| + isolation between CPU threads running on the same core. |
| + |
| +These CPU features may impact performance when used and can be enabled |
| +per process on a case-by-case base. |
| + |
| +The sysfs file showing Spectre variant 2 mitigation status is: |
| + |
| + /sys/devices/system/cpu/vulnerabilities/spectre_v2 |
| + |
| +The possible values in this file are: |
| + |
| + - Kernel status: |
| + |
| + ==================================== ================================= |
| + 'Not affected' The processor is not vulnerable |
| + 'Vulnerable' Vulnerable, no mitigation |
| + 'Mitigation: Full generic retpoline' Software-focused mitigation |
| + 'Mitigation: Full AMD retpoline' AMD-specific software mitigation |
| + 'Mitigation: Enhanced IBRS' Hardware-focused mitigation |
| + ==================================== ================================= |
| + |
| + - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is |
| + used to protect against Spectre variant 2 attacks when calling firmware (x86 only). |
| + |
| + ========== ============================================================= |
| + 'IBRS_FW' Protection against user program attacks when calling firmware |
| + ========== ============================================================= |
| + |
| + - Indirect branch prediction barrier (IBPB) status for protection between |
| + processes of different users. This feature can be controlled through |
| + prctl() per process, or through kernel command line options. This is |
| + an x86 only feature. For more details see below. |
| + |
| + =================== ======================================================== |
| + 'IBPB: disabled' IBPB unused |
| + 'IBPB: always-on' Use IBPB on all tasks |
| + 'IBPB: conditional' Use IBPB on SECCOMP or indirect branch restricted tasks |
| + =================== ======================================================== |
| + |
| + - Single threaded indirect branch prediction (STIBP) status for protection |
| + between different hyper threads. This feature can be controlled through |
| + prctl per process, or through kernel command line options. This is x86 |
| + only feature. For more details see below. |
| + |
| + ==================== ======================================================== |
| + 'STIBP: disabled' STIBP unused |
| + 'STIBP: forced' Use STIBP on all tasks |
| + 'STIBP: conditional' Use STIBP on SECCOMP or indirect branch restricted tasks |
| + ==================== ======================================================== |
| + |
| + - Return stack buffer (RSB) protection status: |
| + |
| + ============= =========================================== |
| + 'RSB filling' Protection of RSB on context switch enabled |
| + ============= =========================================== |
| + |
| +Full mitigation might require a microcode update from the CPU |
| +vendor. When the necessary microcode is not available, the kernel will |
| +report vulnerability. |
| + |
| +Turning on mitigation for Spectre variant 1 and Spectre variant 2 |
| +----------------------------------------------------------------- |
| + |
| +1. Kernel mitigation |
| +^^^^^^^^^^^^^^^^^^^^ |
| + |
| + For the Spectre variant 1, vulnerable kernel code (as determined |
| + by code audit or scanning tools) is annotated on a case by case |
| + basis to use nospec accessor macros for bounds clipping :ref:`[2] |
| + <spec_ref2>` 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 equivalent return trampolines (retpolines) |
| + :ref:`[3] <spec_ref3>` :ref:`[9] <spec_ref9>` 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 Clang compiler, the compiler needs |
| + to support -mretpoline-external-thunk option. The kernel config |
| + CONFIG_RETPOLINE needs to be turned on, and the CPU needs to run with |
| + the latest updated microcode. |
| + |
| + On Intel Skylake-era systems the mitigation covers most, but not all, |
| + cases. See :ref:`[3] <spec_ref3>` for more details. |
| + |
| + On CPUs with hardware mitigation for Spectre variant 2 (e.g. Enhanced |
| + IBRS on x86), retpoline is automatically disabled at run time. |
| + |
| + The retpoline mitigation is turned on by default on vulnerable |
| + CPUs. It can be forced on or off by the administrator |
| + via the kernel command line and sysfs control files. See |
| + :ref:`spectre_mitigation_control_command_line`. |
| + |
| + On x86, indirect branch restricted speculation is turned on by default |
| + before invoking any firmware code to prevent Spectre variant 2 exploits |
| + using the firmware. |
| + |
| + Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=y |
| + and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes |
| + attacks on the kernel generally more difficult. |
| + |
| +2. User program mitigation |
| +^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| + |
| + User programs can mitigate Spectre variant 1 using LFENCE or "bounds |
| + clipping". For more details see :ref:`[2] <spec_ref2>`. |
| + |
| + 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 the branch |
| + target buffer left by malicious software. Alternatively, the |
| + programs can disable their indirect branch speculation via prctl() |
| + (See Documentation/spec_ctrl.txt). |
| + 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. |
| + |
| + Restricting indirect branch speculation on a user program will |
| + also prevent the program from launching a variant 2 attack |
| + on x86. All sand-boxed SECCOMP programs have indirect branch |
| + speculation restricted by default. Administrators can change |
| + that behavior via the kernel command line and sysfs control files. |
| + See :ref:`spectre_mitigation_control_command_line`. |
| + |
| + Programs that disable their indirect branch speculation will have |
| + more overhead and run slower. |
| + |
| + User programs should use address space randomization |
| + (/proc/sys/kernel/randomize_va_space = 1 or 2) to make attacks more |
| + difficult. |
| + |
| +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 code |
| + uses nospec accessor macros for "bounds clipping", to avoid any |
| + 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 or Enhanced IBRS to prevent consumption of |
| + poisoned entries in branch target buffer left by rogue guests. It also |
| + flushes the return stack buffer on every VM exit to prevent a return |
| + stack buffer 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 in the same CPU hardware thread, |
| + the branch target buffer is sanitized by flushing before switching |
| + to a new guest on a CPU. |
| + |
| + The above mitigations are turned on by default on vulnerable CPUs. |
| + |
| + To mitigate guest-to-guest attacks from sibling thread when SMT is |
| + in use, an untrusted guest running in the sibling thread can have |
| + its indirect branch speculation disabled by administrator via prctl(). |
| + |
| + The kernel also allows guests to use any microcode based mitigation |
| + they choose to use (such as IBPB or STIBP on x86) to protect themselves. |
| + |
| +.. _spectre_mitigation_control_command_line: |
| + |
| +Mitigation control on the kernel command line |
| +--------------------------------------------- |
| + |
| +Spectre variant 2 mitigation can be disabled or force enabled at the |
| +kernel command line. |
| + |
| + nospectre_v2 |
| + |
| + [X86] Disable all mitigations for the Spectre variant 2 |
| + (indirect branch prediction) vulnerability. System may |
| + allow data leaks with this option, which is equivalent |
| + to spectre_v2=off. |
| + |
| + |
| + spectre_v2= |
| + |
| + [X86] Control mitigation of Spectre variant 2 |
| + (indirect branch speculation) vulnerability. |
| + The default operation protects the kernel from |
| + user space attacks. |
| + |
| + on |
| + unconditionally enable, implies |
| + spectre_v2_user=on |
| + off |
| + unconditionally disable, implies |
| + spectre_v2_user=off |
| + auto |
| + kernel detects whether your CPU model is |
| + vulnerable |
| + |
| + Selecting 'on' will, and 'auto' may, choose a |
| + mitigation method at run time according to the |
| + CPU, the available microcode, the setting of the |
| + CONFIG_RETPOLINE configuration option, and the |
| + compiler with which the kernel was built. |
| + |
| + Selecting 'on' will also enable the mitigation |
| + against user space to user space task attacks. |
| + |
| + Selecting 'off' will disable both the kernel and |
| + the user space protections. |
| + |
| + Specific mitigations can also be selected manually: |
| + |
| + retpoline |
| + replace indirect branches |
| + retpoline,generic |
| + google's original retpoline |
| + retpoline,amd |
| + AMD-specific minimal thunk |
| + |
| + Not specifying this option is equivalent to |
| + spectre_v2=auto. |
| + |
| +For user space mitigation: |
| + |
| + spectre_v2_user= |
| + |
| + [X86] Control mitigation of Spectre variant 2 |
| + (indirect branch speculation) vulnerability between |
| + user space tasks |
| + |
| + on |
| + Unconditionally enable mitigations. Is |
| + enforced by spectre_v2=on |
| + |
| + off |
| + Unconditionally disable mitigations. Is |
| + enforced by spectre_v2=off |
| + |
| + prctl |
| + Indirect branch speculation is enabled, |
| + but mitigation can be enabled via prctl |
| + per thread. The mitigation control state |
| + is inherited on fork. |
| + |
| + prctl,ibpb |
| + Like "prctl" above, but only STIBP is |
| + controlled per thread. IBPB is issued |
| + always when switching between different user |
| + space processes. |
| + |
| + seccomp |
| + Same as "prctl" above, but all seccomp |
| + threads will enable the mitigation unless |
| + they explicitly opt out. |
| + |
| + seccomp,ibpb |
| + Like "seccomp" above, but only STIBP is |
| + controlled per thread. IBPB is issued |
| + always when switching between different |
| + user space processes. |
| + |
| + auto |
| + Kernel selects the mitigation depending on |
| + the available CPU features and vulnerability. |
| + |
| + Default mitigation: |
| + If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl" |
| + |
| + Not specifying this option is equivalent to |
| + spectre_v2_user=auto. |
| + |
| + In general the kernel by default selects |
| + reasonable mitigations for the current CPU. To |
| + disable Spectre variant 2 mitigations, boot with |
| + spectre_v2=off. Spectre variant 1 mitigations |
| + cannot be disabled. |
| + |
| +Mitigation selection guide |
| +-------------------------- |
| + |
| +1. Trusted userspace |
| +^^^^^^^^^^^^^^^^^^^^ |
| + |
| + If all userspace applications are from trusted sources and do not |
| + execute externally supplied untrusted code, then the mitigations can |
| + be disabled. |
| + |
| +2. Protect sensitive programs |
| +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| + |
| + For security-sensitive programs that have secrets (e.g. crypto |
| + keys), protection against Spectre variant 2 can be put in place by |
| + disabling indirect branch speculation when the program is running |
| + (See Documentation/spec_ctrl.txt). |
| + |
| +3. Sandbox untrusted programs |
| +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| + |
| + Untrusted programs that could be a source of attacks can be cordoned |
| + off by disabling their indirect branch speculation when they are run |
| + (See Documentation/spec_ctrl.txt). |
| + This prevents untrusted programs from polluting the branch target |
| + buffer. All programs running in SECCOMP sandboxes have indirect |
| + branch speculation restricted by default. This behavior can be |
| + changed via the kernel command line and sysfs control files. See |
| + :ref:`spectre_mitigation_control_command_line`. |
| + |
| +3. High security mode |
| +^^^^^^^^^^^^^^^^^^^^^ |
| + |
| + All Spectre variant 2 mitigations can be forced on |
| + at boot time for all programs (See the "on" option in |
| + :ref:`spectre_mitigation_control_command_line`). This will add |
| + overhead as indirect branch speculations for all programs will be |
| + restricted. |
| + |
| + On x86, branch target buffer will be flushed with IBPB when switching |
| + to a new program. STIBP is left on all the time to protect programs |
| + against variant 2 attacks originating from programs running on |
| + sibling threads. |
| + |
| + Alternatively, STIBP can be used only when running programs |
| + whose indirect branch speculation is explicitly disabled, |
| + while IBPB is still used all the time when switching to a new |
| + program to clear the branch target buffer (See "ibpb" option in |
| + :ref:`spectre_mitigation_control_command_line`). This "ibpb" option |
| + has less performance cost than the "on" option, which leaves STIBP |
| + on all the time. |
| + |
| +References on Spectre |
| +--------------------- |
| + |
| +Intel white papers: |
| + |
| +.. _spec_ref1: |
| + |
| +[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>`_. |
| + |
| +.. _spec_ref2: |
| + |
| +[2] `Bounds check bypass <https://software.intel.com/security-software-guidance/software-guidance/bounds-check-bypass>`_. |
| + |
| +.. _spec_ref3: |
| + |
| +[3] `Deep dive: Retpoline: A branch target injection mitigation <https://software.intel.com/security-software-guidance/insights/deep-dive-retpoline-branch-target-injection-mitigation>`_. |
| + |
| +.. _spec_ref4: |
| + |
| +[4] `Deep Dive: Single Thread Indirect Branch Predictors <https://software.intel.com/security-software-guidance/insights/deep-dive-single-thread-indirect-branch-predictors>`_. |
| + |
| +AMD white papers: |
| + |
| +.. _spec_ref5: |
| + |
| +[5] `AMD64 technology indirect branch control extension <https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf>`_. |
| + |
| +.. _spec_ref6: |
| + |
| +[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf>`_. |
| + |
| +ARM white papers: |
| + |
| +.. _spec_ref7: |
| + |
| +[7] `Cache speculation side-channels <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/download-the-whitepaper>`_. |
| + |
| +.. _spec_ref8: |
| + |
| +[8] `Cache speculation issues update <https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/latest-updates/cache-speculation-issues-update>`_. |
| + |
| +Google white paper: |
| + |
| +.. _spec_ref9: |
| + |
| +[9] `Retpoline: a software construct for preventing branch-target-injection <https://support.google.com/faqs/answer/7625886>`_. |
| + |
| +MIPS white paper: |
| + |
| +.. _spec_ref10: |
| + |
| +[10] `MIPS: response on speculative execution and side channel vulnerabilities <https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/>`_. |
| + |
| +Academic papers: |
| + |
| +.. _spec_ref11: |
| + |
| +[11] `Spectre Attacks: Exploiting Speculative Execution <https://spectreattack.com/spectre.pdf>`_. |
| + |
| +.. _spec_ref12: |
| + |
| +[12] `NetSpectre: Read Arbitrary Memory over Network <https://arxiv.org/abs/1807.10535>`_. |
| + |
| +.. _spec_ref13: |
| + |
| +[13] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://www.usenix.org/system/files/conference/woot18/woot18-paper-koruyeh.pdf>`_. |