| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <877de2e4-9189-2937-1014-4bfaf90503a5@infradead.org>
Date: Thu, 20 Jun 2019 12:50:41 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Tim Chen <tim.c.chen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
Jonathan Corbet <corbet@....net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ben Greear <greearb@...delatech.com>, stable@...r.kernel.org,
Andi Kleen <ak@...ux.intel.com>,
Dave Hansen <dave.hansen@...el.com>,
Jun Nakajima <jun.nakajima@...el.com>,
Jiri Kosina <jikos@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Tom Lendacky <thomas.lendacky@....com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
David Woodhouse <dwmw@...zon.co.uk>,
Asit Mallick <asit.k.mallick@...el.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Jon Masters <jcm@...hat.com>,
Waiman Long <longman9394@...il.com>,
Borislav Petkov <bp@...en8.de>,
Mark Gross <mgross@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>, x86@...nel.org
Subject: Re: [PATCH v5] Documentation: Add section about CPU vulnerabilities
for Spectre
On 6/19/19 2:17 PM, Tim Chen wrote:
> 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@...ux.intel.com>
> Signed-off-by: Andi Kleen <ak@...ux.intel.com>
> Co-developed-by: Tim Chen <tim.c.chen@...ux.intel.com>
> Signed-off-by: Tim Chen <tim.c.chen@...ux.intel.com>
> Reviewed-by: Thomas Gleixner <tglx@...utronix.de>
> Cc: stable@...r.kernel.org
Hi,
Please see the typo comments below.
Nice writeup.
Thanks.
> ---
> Documentation/admin-guide/hw-vuln/index.rst | 1 +
> Documentation/admin-guide/hw-vuln/spectre.rst | 697 ++++++++++++++++++
> Documentation/userspace-api/spec_ctrl.rst | 2 +
> 3 files changed, 700 insertions(+)
> create mode 100644 Documentation/admin-guide/hw-vuln/spectre.rst
> diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst
> new file mode 100644
> index 000000000000..42936f223a53
> --- /dev/null
> +++ b/Documentation/admin-guide/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 bypass conditional branch instructions
bypasses
> +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 an gadget. An attacker's
a gadget.
> +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 from the sibling thread, as level 1 cache and branch target buffer
from the
> +(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 an microcode update from the CPU
a microcode
> +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) are annotated on a case by case
is annotated
> + 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 :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`)
end above sentence with a '.'
> + 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 overheads and run slower.
? overhead
> +
> + 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 chose to use (such as IBPB or STIBP on x86) to protect themselves.
choose
> +
> +.. _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
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 :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
> +
> +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 :ref:`Documentation/userspace-api/spec_ctrl.rst <set_spec_ctrl>`).
> + 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>`_.
--
~Randy
Powered by blists - more mailing lists