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@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: Thomas Gleixner tglx@linutronix.de Cc: stable@vger.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`_.