Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598

Executive Summary

Intel published an update to this guidance in April 2024 in response to new external research that has identified additional disclosure gadgets in the Linux* kernel. In light of these new findings, customers may wish to implement additional software hardening for Branch History Injection (BHI) and Intra-mode Branch Target Injection (IMBTI) beyond the original recommended mitigations discussed in the initial version of this document. Refer to the Additional Hardening Options section and the Guidelines for Applying Additional Hardening Options section to address these new developments.

Introduction

Branch Target Injection (BTI) (sometimes referred to as Spectre variant 2) is a known cross-domain transient execution attack (TEA) where an attacker may seek to cause a disclosure gadget to be speculatively executed after an indirect branch prediction.

Generally, transient execution attacks require an attacker to be able to run code on the same machine (or the same virtual machine) as the data they are attempting to read, but do not have access to the data (such as where privilege-level isolation is in place). The recommendations in this article are applicable to situations where transient execution attacks are within the user's threat model.

Intra-mode BTI (IMBTI) refers to a variant of BTI where an indirect branch speculates to an aliased predictor entry for a different indirect branch¹ in the same predictor mode at the predicted target will transiently execute. Such predictor entries may contain targets corresponding to near return instructions, even if these branches were only transiently executed. Managed runtimes can provide an attacker with the means to create the aliasing required for intra-mode BTI attacks. IMBTI has been assigned CVE-2022-0002 with a CVSS base score of 4.7 (Medium) CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N.

Branch History Injection (BHI) describes a specific form of intra-mode BTI, where an attacker may manipulate branch history before transitioning from user to supervisor mode (or from VMX non-root/guest to root mode) in an effort to cause an indirect branch predictor to select a specific predictor entry for an indirect branch, and a disclosure gadget at the predicted target will transiently execute. This may be possible since the relevant branch history may contain branches taken in previous security contexts, and in particular, in other predictor modes. BHI as been assigned CVE-2022-0001 with a CVSS base score of 4.7 (Medium) CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N.

Update: Since this guidance was originally published in 2022, the VU Amsterdam researchers have proposed new software techniques to identify and potentially exploit disclosure gadgets using BHI. Intel has added an additional section to this guidance (Guidelines for Applying Additional Hardening Options) to address this development. OS and VMM software vendors may wish to consider a broader range of potential approaches, such as those described in the Additional Hardening Options section, when deciding on appropriate mitigation options. The Software BHB-clearing Sequence section has been updated to add descriptive names for each software sequence, and the Software Mitigations in Migration Pools section has also been updated to describe improvements to the virtual MSR interface.

Researchers from VU Amsterdam originally demonstrated in-domain BHI and intra-mode BTI attacks against the Linux* kernel by creating a kernel-mode disclosure gadget using a feature known as eBPF (the extended Berkeley Packet Filter). The indirect branch in the Linux system call dispatcher may then speculatively select an indirect branch predictor entry—based on partially attacker-controlled branch history—which corresponds to the attacker’s eBPF disclosure gadget. While the kernel eBPF verifier mitigates most transient execution attack variants, at the time of writing it does not defend against this form of attack.

On BHI-affected processors, Intel recommends disabling Linux’s “unprivileged eBPF,” enabling eIBRS and enabling SMEP. This will mitigate BHI as well as other intra-mode BTI attacks using eBPF. This makes transient execution attacks more difficult in general and is the current default configuration for most Linux distributions.

In addition to the originally demonstrated attacks using eBPF, other BHI attacks can be mitigated by adding LFENCE to specific identified gadgets that are found to be exploitable. This article provides details on mitigation options which could be considered for various threat models, including software BHB clearing sequences which can be executed when transitioning between domains, BHB-specific indirect predictor disable controls, or retpoline.

Future processors are expected to mitigate BHI attacks in hardware, and this article also describes the way in which future hardware will enumerate such hardware mitigation. In situations where these BHI mitigations are not viable, or environments where intra-mode BTI is a concern (for example, where managed runtimes like “unprivileged eBPF” are in use), this article also presents potential mitigations for intra-mode BTI.

Background

This section presents some additional background information that may be useful for understanding the issue and vulnerabilities described in this article. This supplements Intel’s previous documentation on Branch Target Injection and the related mitigations, such as Indirect Branch Restricted Speculation (IBRS).

Intra-mode Branch Prediction

IBRS is intended to prevent software executed in less privileged predictor modes from controlling the indirect branch prediction targets of software executed in more privileged predictor modes²; with eIBRS, indirect branch predictions do not use targets from branches in other predictor modes.

However, transient execution attacks can also occur within a domain ("in-domain"); a possible  example is a web browser running JITed JavaScript* code. Managed runtimes, such as JavaScript engines and Linux’s eBPF, may allow an attacker to influence the code which will be generated and run in another domain. Intel provides managed runtime guidance for mitigating intra-mode Branch Target Injection (BTI) and other TEAs where untrusted code is present in the same domain. Intel also provides specific guidance for hardening Linux’s eBPF against some specific attacks in Mitigation Overview for Side Channel Exploits in Linux.

Note that, as previously documented, fall-through speculation to instruction bytes following an indirect JMP/CALL may also occur.

Branch History and the Branch History Buffer (BHB)

Branches can be predicted based on past behavior, so other domains may still be able to influence indirect branch predictions even without intra-mode BTI. For example, making a read system call that results in the OS system call dispatcher branching to sys_read may cause later executions of that branch to predict sys_read as the target.

The Branch History Buffer (BHB) is used to improve the accuracy of branch predictions, including indirect branch predictions, by recording recent branch history. The BHB can influence the choice of indirect branch predictor entry, and although branch predictor entries are isolated between modes when eIBRS is enabled or IBRS is applied after transition, on many current Intel processors the BHB itself is not isolated between modes. For example, a prediction for an indirect branch in OS system call dispatcher may be based on a BHB containing the branch history from user-mode branches. 

Mitigation Recommendations

The recommendations below are near-term guidance intended to help those in the industry make informed decisions about mitigating these potential attacks. This section provides recommendations for mitigating the BHI attack developed by the researchers from VU Amsterdam as well as related potential intra-mode BTI attacks, with a focus on OS and VMM mitigations. This section also provides guidance for mitigating any other disclosure gadgets that may be identified in the future which could allow potential BHI attacks.

Linux* Kernel: Disable Unpriviliged eBPF

Privileged managed runtimes that can be configured to allow an unprivileged user to generate and execute code in a privileged domain—such as Linux’s “unprivileged eBPF” —significantly increase the risk of transient execution attacks, even when defenses against intra-mode BTI are present. In general, privileged managed runtimes that run unprivileged code can allow attackers to create gadgets and have been demonstrated to be useful for a range of other attacks, including architectural attacks. Administrators should be aware of the possibility of such attacks and carefully consider their threat model before enabling privileged managed runtimes for unprivileged users.

The kernel can be configured to deny access to unprivileged eBPF by default, while still allowing administrators to enable it at runtime where needed. This was already the default for many Linux distributions, such as Debian*, Ubuntu*, Red Hat*, Fedora*, and Oracle Linux*, and is the default for Linux 5.16+. Other Linux kernels can set this default using CONFIG_BPF_UNPRIV_DEFAULT_OFF (which should be available in Linux kernel 5.13+, as well as recent stable kernels). Unprivileged eBPF can be also be disabled or enabled at runtime using the kernel.unprivileged_bpf_disabled sysctl.

Continue to Enable SMEP and enhanced IBRS

SMEP and enhanced IBRS³ are hardware mitigations which are already enabled by default by most operating systems when supported. Intel recommends continuing to enable both SMEP and eIBRS by default and using IBPB on context switches where needed. eIBRS prevents Branch Target Injection (Spectre v2) by preventing less privileged modes from specifying the predicted targets of indirect jumps. SMEP prevents supervisor mode execution from user mode pages, including transient execution. IBPB is a branch prediction barrier which can be used to isolate different contexts from each other.  These are important for defense-in-depth in addition to mitigating the original Branch Target Injection attack.

Processors Without eIBRS

On parts that do not support eIBRS, these BHI attacks can be mitigated by following the existing guidance for related branch target injection attacks.

Mitigating Potential Disclosure Gadgets

Potential transient execution at indirect branch targets can be mitigated by using techniques such as adding LFENCE. Similar techniques are also used to mitigate existing transient execution attacks such as Bounds Check Bypass, and can be applied on a case-by-case basis to any potentially exploitable disclosure gadgets under the circumstances where such approach is feasible in terms of performance and execution. Considerations for a specific code base generally include its size, maintenance and updates, and the number of identified disclosure gadgets.

In situations where it is not viable or desired to mitigate disclosure gadgets in this way, BHI attacks (and where relevant, intra-mode BTI attacks) can be mitigated using the alternative mitigations described in the Additional Hardening Options section. Where such mitigations are in place, mitigating individual disclosure gadgets is no longer necessary to defend against BHI and/or intra-mode BTI attacks.

Additional Hardening Options

Intel expects the recommendations in the Mitigation Recommendations section to be sufficient for most known threat models. This section provides information on alternative and additional hardening options that may not be generally applicable; caveats may apply, or they may only be relevant for some parts. Refer to the Guidelines for Applying Additional Hardening Options section for updated guidance on mitigations.

Indirect Branch Predictor Controls

Some recent and future Intel processors will support additional controls for indirect branch predictors, exposed as bits in the IA32_SPEC_CTRL MSR. The enumeration of these controls is specified in the Enumeration section, and the controls are implemented as bits in the IA32_SPEC_CTRL MSR. 

BHI attacks against OSes and VMMs can be mitigated using the BHI_DIS_S indirect predictor control. This prevents predicted targets of indirect branches executed in CPL0, CPL1, or CPL2 from being selected based on branch history from branches executed in CPL3, other than RSB-based return predictions (which can be mitigaated with other methods, such as SMEP).

While set in the VMX root (host), it also prevents predicted targets executed in CPL0 (ring 0/root) from being selected based on branch history from branches executed in a VMX non-root (guest). It may not prevent predicted targets executed in CPL3 of VMX root from being based on branch history for branches executed in a VMX non-root (guest). Future processors may lower the performance overhead of BHI_DIS_S.

Intra-mode BTI

Where intra-mode BTI is a concern, such as when managed runtimes are in use, IPRED_DIS_U or IPRED_DIS_S indirect predictor controls can be applied. IPRED_DIS_U (affecting CPL3) and IPRED_DIS_S (affecting CPL<3), when active, prevent transient execution at predicted targets of an indirect near JMP/CALL before the target is resolved⁴. This includes transient execution at past targets of that same branch. Transient execution at predicted targets of a near RET prediction will only occur for RSB-based return predictions, or for linear address 0. Note that, as previously documented, fall-through speculation to instruction bytes following an indirect JMP/CALL or speculation to linear address 0 may still occur. 

Future Processors May Mitigate BHI in Hardware

Future processors may mitigate BHI in hardware, resulting in the behavior described above for BHI_DIS_S being enabled by default. Software can determine whether this is the case by checking whether BHI_NO is enumerated by the processor; see the Enumeration section below. On processors where this is enumerated, no additional mitigation is required to prevent BHI. However, where intra-mode BTI is a concern (such as where managed runtimes are present), suitable mitigations may still be necessary on these processors.

Retpoline

OS/VMM vendors can apply the retpoline mitigation to indirect branches on affected processors⁵. Intel recommends continuing to enable eIBRS wherever available, regardless of any other mitigations. Retpoline is a technique already described in existing guidance: Retpoline: A Branch Target Injection Mitigation. For example, on Linux, retpoline can be applied to existing kernels through a boot-time option (spectre_v2=retpoline).

As was already documented in our existing guidance, retpoline may not be fully effective on Intel® Atom processors based on microarchitectures code named Goldmont Plus and Tremont. Alternative options for those processors can be found in the Intel® Atom Goldmont Plus and Tremont Mitigation section. Some processors are being provided a microcode update that improves retpoline performance on these processors compared to previous microcode updates. Refer to the table in the Processors that Require MCU for Retpoline Performance Improvement section for a list of processors for which a microcode update is being provided to improve retpoline performance.  

Retpoline is also incompatible with CET shadow stack (CET-SS), which provides a mitigation for a wide range of attacks, including architectural attacks. On recent processors, Intel recommends considering the other options (which are compatible with CET-SS), such as those described in the Indirect Branch Predictor Controls section, rather than retpoline.

Finally, some processors may use alternate predictors for RETs when the RSB predictor is empty. As documented in our existing retpoline guidance, this behavior occurs on some older processors based on Skylake microarchitecture. Similar behavior occurs on more recent processors, where RETs may use alternate predictors but the targets are restricted to branch predictor entries of the current predictor domain. These newer processors will expose a new RRSBA (Restricted RSB Alternate) enumeration⁶. Where software is using retpoline as a mitigation for BHI or intra-mode BTI, and the processor both enumerates RRSBA and enumerates RRSBA_DIS controls, it should disable this behavior. This can be done using the new RRSBA_DIS_S (affecting CPL < 3) and RRSBA_DIS_U (affecting CPL3) indirect predictor controls. When these controls are set, transient execution at predicted targets of a near RET prediction will only occur for RSB-based return predictions, or for linear address 0.

Note that Alder Lake processors may also underflow the RSB more frequently when retpoline is used. Any future microcode update which enumerates RRSBA will improve this behavior. Software using retpoline as a mitigation for BHI or intra-mode BTI should use these new indirect predictor controls to disable alternate predictors for RETs.

Intel® Atom Goldmont Plus and Tremont Mitigation

Retpoline may not be a fully effective branch target injection mitigation on processors which are based on Intel Atom microarchitectures code named Goldmont Plus and Tremont, as documented in our existing guidance. On such processors, an LFENCE;JMP sequence may be an alternative for retpoline, although this is not architecturally guaranteed. Instructions may still be speculatively executed at the predicted near JMP target, which can allow some forms of shallow gadgets (for example, revealing register values) to be transiently executed.

Intel is not currently evaluating LFENCE;JMP as an option other than for processors based on Goldmont Plus and Tremont microarchitectures, given the possibility of a sufficiently large transient window to execute a disclosure gadget.

CET-IBT

Recent Intel CPUs support a feature known as CET-IBT (Indirect Branch Tracking) that requires indirect branch targets to start with an ENDBRANCH instruction. When enabled, CET-IBT limits speculative execution at indirect branch targets that do not start with ENDBRANCH, which provides defense-in-depth to prevent the use of unintended targets both architecturally and speculatively. On Alder Lake, Sapphire Rapids, and some future processors, the potential speculation window at a predicted target that does not start with ENDBRANCH is limited to two instructions (and typically fewer), although this may not be the case for earlier implementations⁷. Other future processors may eliminate this speculation window entirely. CET-IBT also limits speculation of the next sequential instructions after an indirect JMP or CALL. CET-IBT can be combined with a callee-based Control Flow Integrity approach, such as FineIBT, that can restrict execution at architecturally incorrect targets that do start with ENDBRANCH. 

Software BHB-clearing Sequence

Another mitigation option is to invoke a software sequence to overwrite the BHB after domain transitions. This mitigates BHI by removing a potential attacker’s control of the BHB. This mitigation is not needed on processors that enumerate BHI_NO as described in the Enumeration of Related Processor Behaviors section or where another BHI mitigation is in place. 

The optimal software sequence to clear the BHB may differ between processors, due to microarchitectural differences such as the number of branches recorded in the BHB. Intel is providing a software sequence which is sufficient to clear the BHB on all processors prior to Alder Lake, which is shown in Listing 1. It is known as the short sequence. Intel is also providing a sequence which is sufficient to clear the BHB on Alder Lake and Sapphire Rapids and later processors with P-cores that do not enumerate BHI_NO, which is shown in Listing 2. It is known as the long sequence. The long sequence will be effective on all processors that do not enumerate BHI_NO and should not be needed on parts that do enumerate BHI_NO.

  	 mov $5, %%ecx
  	 call 801f
  	 jmp 805f
  	 .align 64
801: call 802f
  	 ret
  	 .align 64
802: movl $5, %%eax
803: jmp 804f
  	 nop
804: sub $1, %%eax
  	 jnz 803b
  	 sub $1, %%ecx
  	 jnz 801b
  	 ret
805:  lfence

Listing 1 (short sequence). Proposed software BHB-clearing sequence for all processors prior to Alder Lake.

  	  mov $12 %%ecx
  	  call 801f
  	  jmp 805f
  	  .align 64
801:  call 802f
  	  ret
  	  .align 64
802:  movl $7, %%eax
803:  jmp 804f
  	  nop
804:  sub $1, %%eax
  	  jnz 803b
  	  sub $1, %%ecx
  	  jnz 801b
  	  ret
805:  lfence

Listing 2 (long sequence): Proposed software BHB-clearing sequence for Alder Lake and Sapphire Rapids.

Aborting an Intel® Transactional Synchronization Extensions (Intel® TSX) transactional region by invoking TSX abort also clears the BHB. The sequence in Listing 3 shows how to enforce this abort; the push/pop are only needed if the RAX register contents should be preserved. This software sequence is an alternative to the sequences above, but it only works on processors that support Intel TSX. The TSX sequence is effective on all current processors with Intel TSX support that do not enumerate BHI_NO and should not be needed on parts that do enumerate BHI_NO. This sequence would be effective on all current processors with Intel TSX support whether or not XBEGIN is configured to always abort, such as when the IA32_TSX_CTRL (0x122) RTM_DISABLE control is set.  

        push %%rax
        xbegin label
        xabort $0
        lfence
label:  pop %%rax

Listing 3 (TSX sequence): Proposed software BHB-clearing sequence based on Intel TSX abort.

These sequences are provided as reference. Software using the above software BHB-clearing sequences should be following the guidance in the Software Mitigations in Migration Pools section so that they remain effective when virtualized (for example, when used in VM migration pools with future processors).

Software Mitigations in Migration Pools

This section discusses situations where the CPUID family/model/stepping or other CPU enumeration exposed to a guest may not reflect the underlying hardware, such as in VM migration pools where guests may be migrated between processors of different microarchitectures. In such cases, software may use a software mitigation that is not effective. In particular, this applies to the short sequence described in the Software BHB-clearing Sequence section, which may not be effective on newer or future processors, and mitigations described in the Retpoline section, which may need the RRSBA_DIS indirect predictor control to be set on processors which enumerate RRSBA.

VMMs can address this by applying the needed controls whenever the guest is operating on a newer processor. For example, if a guest is using the BHB-clearing sequence on transitions into CPL0 to mitigate BHI, the VMM can use the “virtual IA32_SPEC_CTRL” VM-execution control to set BHI_DIS_S (or IPRED_DIS_S) on newer hardware which does not enumerate BHI_NO. Similarly, if a guest is using retpoline to mitigate intra-mode BTI in CPL0, the VMM can set RRSBA_DIS_S when the guest runs on hardware which enumerates RRSBA.

Enabling these hardware controls for guests which are not using these software mitigations is not necessary and may cause performance impact unnecessarily. To avoid that, Intel is documenting a set of virtual MSRs that can allow guests to notify VMMs whether or not they are using specific software mitigations, allowing a VMM to enable these hardware controls only where necessary.

The Intel-defined virtual MSRs described in this section are only supported when IA32_ARCH_CAPABILITIES bit 63 is set. In the future, a separate whitepaper will document Intel-defined virtual MSRs, including these. Specific MSR addresses and the corresponding bits can be found in the Virtualization Execution Control section.

Requirements for Virtualized Operating Systems

Guests can check whether they are running under a VMM which supports this virtual MSR interface for notifying VMMs about software mitigations by checking bit 63 of IA32_ARCH_CAPABILITIES, and if set, by checking whether MITIGATION_CTRL_SUPPORT (bit 0) is set in MSR_VIRTUAL_ENUMERATION. If either of these bits are not set, then the software mitigations interface is not supported.

Where the interface is supported, Intel is initially defining two scenarios:

Guest OSes that clear the BHB (as documented in the Software BHB-clearing Sequence section) on transitions into CPL0 to mitigate BHI should check whether BHB_CLEAR_SEQ_S_SUPPORT is set in MSR_VIRTUAL_MITIGATION_ENUM. If this bit is set, then guest OSes can request support for this scenario by setting the corresponding BHB_CLEAR_SEQ_S_USED bit in MSR_VIRTUAL_MITIGATION_CTRL. Guest OSes can then rely on the “short” BHB-clearing sequence to be effective.

Guest OSes that are using long or TSX sequences can optionally clear BHB_CLEAR_SEQ_S_USED bit in order to communicate this to the VMM⁸.

When a guest OS is using retpoline in CPL0 to mitigate intra-mode BTI or BHI, they OS should check whether RETPOLINE_S_SUPPORT is set in MSR_VIRTUAL_MITIGATION_ENUM. If it is set, then the OS it can request support for this scenario by setting the corresponding bit in MSR_VIRTUAL_MITIGATION_CTRL.

Requirements for VMMs that Virtualize CPUID Family/Model/Stepping

This section is relevant to VMMs that enumerate a CPUID family/model to a guests for which a particular BHB-clearing sequence or retpoline is sufficient, but which may also run that guest on a processor for which that mitigation is not sufficient. Such VMMs should both virtualize MSR reads of IA32_ARCH_CAPABILITIES MSR such that bit 63 is set and reads of MSR_VIRTUAL_ENUMERATION such that bit 0 is read as 1. These VMMs should also add the support indicated in both of the next two sections. 

VMM Support for BHB-clearing Software Sequences

VMMs should virtualize MSR reads of MSR_VIRTUAL_MITIGATION_ENUM such that bit 0 is read as 1. If the guest does an MSR write to MSR_VIRTUAL_MITIGATION_CTRL that sets bit 0, BHB_CLEAR_SEQ_S_USED, then the guest is using the short sequence⁸ to mitigate BHI.

In order for the guest mitigation to be effective, the VMM should use the “virtualize IA32_SPEC_CTRL” VM-execution control to cause BHI_DIS_S to be set whenever the guest is running on processors for which that short BHB-clearing sequence may not be effective (such as on Alder Lake/Sapphire Rapids and future processors). Specifically, the VMM can set the VM-execution control, set the bit corresponding to BHI_DIS_S in the SPEC_CTRL_MASK VMCS field and set IA32_SPEC_CTRL[BHI_DIS_S] when the guest runs on such processors.  As a specific example, for a VM migration pool that runs Intel® Xeon® processors based on both Ice Lake and Sapphire Rapids microarchitectures, if the guest sets BHB_CLEAR_SEQ_S_USED then the VMM should cause BHI_DIS_S to be set whenever the guest runs on a Sapphire Rapids processor. 

A VMM may also choose to cause BHI_DIS_S to be set in the applicable situations even when BHB_CLEAR_SEQ_S_SUPPORTED is not enumerated, or when the virtual MSR interface is not supported at all by a VMM.

VMM Support for Retpoline

VMMs should virtualize MSR reads of MSR_VIRTUAL_MITIGATION_ENUM such that bit 1, RETPOLINE_S_SUPPORT, is read as 1. If the guest does an MSR write to MSR_VIRTUAL_MITIGATION_CTRL that sets bit 1, RETPOLINE_S_USED, then the guest may use retpoline to mitigate BHI and intra-mode BTI attacks in CPL0.

In order for the guest mitigation to be effective, the VMM should use “virtualize IA32_SPEC_CTRL” VM-execution control to cause RRSBA_DIS_S to be set whenever the guest OS is using retpoline. Specifically, the VMM can set the VM-execution control, set the bit corresponding to RRSBA_DIS_S in the SPEC_CTRL_MASK VMCS field and set IA32_SPEC_CTRL[RRSBA_DIS_S] when the guest runs on such processors. As a specific example, for a VM migration pool that runs Intel Xeon processors based on both Ice Lake and Sapphire Rapids microarchitectures, if the guest sets RETPOLINE_S_USED then the VMM should cause RRSBA_DIS_S to be set whenever the guest runs on a Sapphire Rapids processor.

Guidelines for Applying Additional Hardening Options

VU Amsterdam researchers have reported new software techniques for BHI, such as using "dispatch gadgets", which contains one indirect branch with an attacker-controlled target address, to facilitate the injection of branch target in the history-based branch predictor, as well as chaining instructions on the speculative execution path to form disclosure gadgets. As such, more potentially exploitable gadgets have been identified in Linux kernel without the need of eBPF. Therefore, software vendors may wish to consider applying the broader mitigations documented in the Additional Hardening Options section. This new technique does not change the scope of impact by BHI in terms of affected processors.

Where operating system or VMM software wishes to deploy these broader BHI mitigations, Intel recommends the following approach:

Operating Systems

On processors which enumerate BHI_NO, OS software does not need to take any additional action. Otherwise, on processors which support BHI_DIS_S, software should set BHI_DIS_S in IA32_SPEC_CTRL to broadly mitigate BHI.

On processors which do not support BHI_DIS_S but do enumerate IBRS_ALL, OS software can mitigate BHI using the short software sequence on domain transitions. 

On processors which do not enumerate IBRS_ALL, OS software does not need to take any additional action when not running in a virtualized environment. However, when running in virtualized environments⁹ where IBRS is enumerated but IBRS_ALL is not enumerated, guests may need to apply mitigations (since the VMM may run the guest on hardware with IBRS_ALL support):

• If OS software is relying on IBRS: Use short software sequence on OS domain transitions.
• If OS software is relying on retpoline:
  • If neither RSBA nor RRSBA is enumerated¹⁰: No additional action needed.
  • If RSB underflow is being mitigated using Call Depth Tracking: No additional action needed.
  • Otherwise (meaning the guest is potentially exposed to RSB underflow): Use the short software sequence on OS domain transitions.

In cases where the OS is using the short software sequence to mitigate BHI, it should use the virtual MSR interface (where available) as documented in the Software Mitigations in Migration Pools section to notify the VMM that it is using the short software sequence. Note that VMMs are expected to default to assuming that guests are using the short software sequence and ensure that it is effective regardless of the actual hardware in use.

On processors (or in virtualized environments) where IBRS is not enumerated, OS software is not expected to take any additional action.

VMM

Where possible, VMMs should enumerate BHI_NO and/or BHI_DIS_S to guests where these are supported by hardware. VMMs may also wish to consider applying the guidance for operating systems to protect themselves, where relevant; and, if using BHI_DIS_S for this purpose, can use IBPB (or a software sequence) to isolate ring 3 of the host from guest behavior.

The VMM should use the “virtualize IA32_SPEC_CTRL” VM-execution control to cause BHI_DIS_S to be set (see the VMM Support for BHB-clearing Software Sequences section) whenever:

• The VMM is running on a processor for which the short software sequence may not be effective:
  • Specifically, it does not enumerate BHI_NO, but does enumerate BHI_DIS_S, and is not an Atom-only¹¹ processor. 
• Neither BHI_DIS_S nor BHI_NO is enumerated to the guest, and IBRS is enumerated to the guest (which implies to the guest that the short sequence will be effective); and
  • The guest has not used virtual MSRs (see the VMM Support for BHB-clearing Software Sequences, and the guidance below) to indicate that it does not rely on the short software sequence to mitigate BHI.

Note that VMMs should enumerate RSBA to guests that may run on processors with RSB Alternate behavior (those which enumerate RSBA). If RSBA is not enumerated to a guest, VMMs should enumerate RRSBA to guests that may run on processors with Restricted RSB Alternate behavior (those which enumerate RRSBA) without RRSBA_DIS_S being set. 

Alternate Approaches for OSes

Intel has also documented software sequences which can be used on OS domain transitions to mitigate BHI on processors where BHI_NO is not enumerated, BHI_DIS_S is enumerated, and BHI_DIS_S is not enabled by OS software:

• The short sequence should be used on Atom-only¹¹ processors. (The short sequence is effective on all cores which report a core type of Atom and do not enumerate BHI_NO, even if other cores are present.)
• Otherwise, the TSX sequence can be used where RTM is supported (and in some other cases¹²).
• Otherwise, the long sequence should be used.

None of these sequences are relevant for processors if processors are not affected by BHI, (BHI_NO is enumerated).

When BHI_DIS_S is not enumerated to a guest but IBRS is enumerated and enabled, guest OSes can assume that the VMM will cause BHI_DIS_S to be set on the underlying hardware to support use of the short software sequence. As documented in VMM Support for BHB-clearing Software Sequences, guest OSes which prefer the software sequences can request that the VMM not set BHI_DIS_S in these cases by clearing the BHB_CLEAR_SEQ_S_USED bit using the virtual MSR interface. In such cases, guests should not assume that the short software sequence will be sufficient to mitigate BHI and need to use the TSX sequence or the long sequence. If BHB_CLEAR_SEQ_S_SUPPORT is not enumerated (meaning virtual MSRs are not supported), then the short software sequence should be sufficient with VMM support (as described in the Guidelines for Applying Additional Hardening Options section).

Virtual MSR Support in VMMs

As documented in VMM Support for BHB-clearing Software Sequences, a VMM can (optionally) support guest OSes which are using alternate approaches to BHI_DIS_S via the virtual MSR interface, by enumerating BHB_CLEAR_SEQ_S_SUPPORTED. To support guest OSes which do not support the virtual MSR interface, VMMs are expected to set the BHB_CLEAR_SEQ_S_USED bit by default. If a guest uses the virtual MSR interface to clear the BHB_CLEAR_SEQ_S_USED bit, the VMM can assume that the guest will use the long or TSX sequence¹³ to mitigate BHI. In this situation, the VMM should not apply BHI_DIS_S underneath such guests. 

VMMs do not need to enumerate BHB_CLEAR_SEQ_S_SUPPORTED if they do not migrate to parts where the short sequence is ineffective, such as where BHI_DIS_S is supported. This can avoid the guest OS using a long or TSX sequence when it is not needed. 

Enumeration

Enumeration of New Indirect Branch Predictor Controls

The controls described in the Indirect Branch Predictor Controls section are exposed as bits in the IA32_SPEC_CTRL MSR. Support for these controls is enumerated in CPUID leaf 7, subleaf 2; bit 1 of EDX indicates support for the indirect predictor disable, bit 2 of EDX indicates support for the bottomless RSB disable, and bit 4 of EDX indicates support for the BHB-focused indirect predictor disable.

Enumeration of Related Processor Behaviors

Note that support for indirect branch predictor controls does not imply that the control is required to be set on that processor to get the documented behavior.

Explicit enumeration is provided for processors with RRSBA behavior. RRSBA behavior allows alternate branch predictors to be used by near RET instructions when the RSB is empty, but the predicted targets of these alternate predictors are restricted to those belonging to the indirect branch predictor entries of the current prediction domain. Such processors that may exhibit RRSBA behavior (when RRSBA_DIS_U or RSBA_DIS_S are not set) will set the RRSBA enumeration bit in the IA32_ARCH_CAPABILITIES MSR.

• IA32_ARCH_CAPABILITIES[RRSBA], bit 19: A value of 1 indicates processor may have the RRSBA alternate prediction behavior, if not disabled by RRSBA_DIS_U or RRSBA_DIS_S.

Future processors may restrict cross-domain branch history influence on indirect branch prediction target selection, regardless of the value of the IA32_SPEC_CTRL[BHI_DIS_S] MSR bit.  Enumeration of BHI_NO indicates that the processor prevents predicted targets of indirect branches executed in CPL0, CPL1, or CPL2 from being selected based on branch history from branches executed in CPL3, other than RSB-based return predictions. It also prevents predicted targets executed in CPL0/1/2 VMX root from being selected based on branch history from branches executed in a VMX non-root (guest). 

• IA32_ARCH_CAPABILITIES[BHI_NO], bit 20: A value of 1 indicates BHI_NO branch prediction behavior, regardless of the value of IA32_SPEC_CTRL[BHI_DIS_S] MSR bit.

Virtualization Execution Control

When “virtualize IA32_SPEC_CTRL” VM-execution control is enabled, the processor supports virtualizing MSR writes and reads to IA32_SPEC_CTRL. This VM-execution control is enabled when the tertiary processor-based VM-execution control bit 7 is set and the tertiary controls are enabled. The support for this VM-execution control is enumerated by bit 7 of the IA32_VMX_PROCBASED_CTLS3 MSR (0x492).

When enabled, two new VM-execution control fields are used:

• The IA32_SPEC_CTRL mask (encoding pair 204AH/204BH) specifies which IA32_SPEC_CTRL bits are exposed to the guest (VMX non-root). When a bit is set in the mask, the guest cannot change the corresponding bit of IA32_SPEC_CTRL.
• The IA32_SPEC_CTRL shadow (encoding pair 204CH/204DH) contains the value of IA32_SPEC_CTRL which is exposed to the guest.

When the control is enabled, and the MSR bitmap is not set to cause a VM exit on an access to IA32_SPEC_CTRL:

• RDMSR to IA32_SPEC_CTRL will return the value of the shadow. 
• WRMSR to IA32_SPEC_CTRL will attempt to write (IA32_SPEC_CTRL & mask) | (EDX:EAX & NOT mask) to IA32_SPEC_CTRL, and update the shadow with the value of EDX:EAX if the write succeeds (does not fault).

Note that software should not include IA32_SPEC_CTRL in VMX MSR save/load lists when the “virtualize IA32_SPEC_CTRL” VM-execution control is set. It is implementation specific whether the “virtualize IA32_SPEC_CTRL” VM-execution control applies to such MSR reads and writes.

Virtual MSRs for Software Mitigations

Table 3 summarizes the Intel-defined virtual MSRs which were described in the Software Mitigations in Migration Pools section. The remaining MSRs between 0x50000003-0x5fffffff are reserved for Intel-defined usages and should not be defined by others.

Affected Processors

The table of affected processors (2022 tab) linked above indicates the processors for which privileged code may be affected by BHI (CVE-2022-0001) and/or intra-mode BTI (CVE-2022-0002) when the IBRS/eIBRS mitigations against BTI are properly applied. For example, this table may indicate that a processor is not affected by intra-mode BTI if IBRS or retpoline applied to privileged (kernel or VMM) code stops all speculative execution at the targets of indirect jumps and calls; even though the behavior behind intra-mode BTI may occur when IBRS or retpoline is not applied (for example, to application code). 

In general, when no mitigations are applied, every processor affected by BTI (Spectre variant 2) would also be affected by intra-mode BTI. BHI and intra-mode BTI are more complex attacks than BTI, and systems for which BTI mitigations were not needed (for example, because all code executed on the system is trusted) are expected to find that BHI and intra-mode BTI will not need mitigating. 

Additional Information

Intel researchers have identified two related behaviors which are described below. Intel continues to invest in internal and external research to attempt to identify any additional related scenarios which could be potentially exploitable. External researchers can report a security vulnerability through the Intel Bug Bounty Program if an exploit is found.

Branch History and Indirect Branch Prediction Barriers

Some operations act as indirect branch prediction barriers by preventing software executed before the barrier from controlling the predicted targets of near indirect branches executed after the barrier. On processors that do not enumerate BHI_NO, these barrier operations may allow near indirect branches encountered after the barrier to be predicted (to targets reached after the barrier) using branch history accumulated before the barrier. This may allow the BHB generated by code executed before the barrier to cause aliasing between two branches encountered after the barrier, so both branches use the same branch predictor target. Intel is not aware of any production code where this behavior could enable a transient execution attack. Parts that enumerate BHI_NO are not affected by this behavior.

Some examples of operations that can act as indirect branch prediction barriers include entering an Intel SGX enclave or system-management mode (SMM), and IBPB. Intel has released a processor microcode update (MCU) that prevents indirect branches encountered after entering an Intel SGX enclave from being predicted using branch history accumulated before entering the enclave. If deemed necessary to a particular threat model, the branch clearing sequence in the Software BHB-clearing Sequence section can be applied by software after any other operation that act as an indirect branch prediction barrier, such as IBPB.

Incomplete Upper Target Isolation on Intel Atom Processors

On many Intel Atom processors that enumerate enhanced IBRS (IBRS_ALL) but not BHI_NO, it may be possible for software in a less privileged domain to specify some upper bits of the branch predictor targets in a more privileged domain even when enhanced IBRS is used. Specifically, the less privileged software may be able to specify some or all of bits 47:29 of the branch prediction target used in the more privileged domain while the remaining target bits are based on a previous branch in that more privileged domain. The less privileged domain cannot directly specify the lower 29 bits of the target. Also, only privileged indirect branches which change bits 47:29 of the RIP register are affected by this behavior. 

Intel is not aware of this behavior enabling a transient execution attack in any production environment using enhanced IBRS. If deemed necessary to a particular threat model, this behavior could be mitigated by replacing indirect branches with retpoline for Gracemont and later microarchitectures or with LFENCE;JMP for Goldmont Plus or Tremont based microarchitectures. This behavior does not affect processors that enumerate BHI_NO. 

Processors Affected by Incomplete Upper Target Isolation

Processors That Require MCU for Retpoline Performance Improvement

The processors listed in this table require microcode updates to improve the performance of the retpoline mitigation. Refer to the Retpoline section for additional information.

References

• Software Security Guidance Home 
• Branch Target Injection (Spectre v2) Advisory Guidance  
• Speculative Execution Side Channel Mitigations (IBRS/eIBRS, IPBP, STIBP, RSB are here )
• Retpoline: A Branch Target Injection Mitigation (Empty RSB mitigation on Skylake generation is in here) 
• Managed Runtime Speculative Execution Side Channel Mitigations 
• Intel Analysis of Speculative Execution Side Channels 
• Mitigation Overview for Side Channel Exploits in Linux*

Example of BHI Mitigation Selection Flow

This is an example of a BHI mitigation flow. This example flow may vary for different OS and VMM environments

Figure 1: Branch History Injection Mitigation Flowchart

Footnotes

1. Intra-mode BTI does not refer to indirect branch predictions using predictor entries which contain targets previously created for the same indirect branch.

2. Note: Supervisor-mode execution prevention (SMEP) should be used to prevent predicted targets of OS near returns using user created return stack buffer (RSB) entries; refer to the IBRS documentation for details.

3. See section 2.4.1.3 in the Speculative Execution Side Channel Mitigations technical paper for more information on IBRS/eIBRS. 

4. Note that this does not cover attacker-controlled jump redirection, which is described in section 18.1.3 “Speculative Behavior when CET is Enabled” of the Intel Software Developers Manual.

5. Refer to the Branch History Injection and Intra-mode Branch Target Injection columns of the consolidated Affected Processors table.

6. For Alder Lake processors, a microcode update may be needed to be loaded for the processor to enumerate RRSBA, as well as to avoid other potential retpoline effectiveness issues. 

7.  The behavior for those earlier implementations is described in section 18.3.8, “Constraining Speculation after Missing ENDBRANCH” of the Intel Software Developers Manual.

8. Note that previous Intel guidance indicated that BHB_CLEAR_SEQ_S_USED should be set whenever any SW sequence was used. The new guidance is to set this bit only when the short sequence is used.

9. CPUID.1.ECX[31] indicates that the software is running in a virtualized environment.

10. If neither RSBA nor RRSBA is enumerated then the guest should not run on a processor with RSB Alternate behavior.

11. The short sequence should be effective on all processors where CPUID reports a core type (CPUID.1A.0.EAX[31:24]) of Atom and do not report being hybrid (CPUID.7.0.EDX[15]), and which do not enumerate BHI_NO (IA32_ARCH_CAPABILITIES[20]).

12. The TSX sequence can be used where RTM (CPUID.7.0.EBX[11]) is enumerated, support for TSX_CTRL is enumerated (IA32_ARCH_CAPABILITIES[7]), or where both (a) RTM_ALWAYS_ABORT (CPUID.7.0.EDX[11]) is enumerated and (b) CPUID.7.0.EDX[13] is not set.

13. The long or TSX sequences will be sufficient to isolate branch history after domain transitions on parts where branch history is not isolated across domain transitions (BHI_NO is not enumerated).