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

ID 758359
Updated 8/4/2022
Version Latest
Public

author-image

By

Branch Target Injection (BTI) (sometimes referred to as Spectre variant 2) is a known cross-domain transient execution attack 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 branch1 in the same predictor mode, and a disclosure gadget at the predicted target will transiently execute. Such predictor entries may contain targets corresponding to the targets of indirect near jump, indirect near call and/or 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.

Researchers from VU Amsterdam have 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 the demonstrated BHI attack 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 demonstrated attacks using eBPF, the possibility exists that there may be other BHI attacks identified in the future. Such potential BHI attacks can be mitigated by adding LFENCE to specific identified gadgets that are found to be exploitable. This article provides details on this and other 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 modes2; with eIBRS, indirect branch predictions do not use targets from branches in other predictor modes.

However, transient execution attacks (TEAs) 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 IBRS3 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 as they are discovered. Intel continues to work with partners to identify and mitigate potentially exploitable 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. 

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. 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 resolved4. 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 processors5. 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) enumeration6. 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 implementations7. 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. Intel is also providing a sequence which is sufficient to clear the BHB on Alder Lake and Sapphire Rapids, which is shown in Listing 2. However, although these software sequences provide mitigation on current processors, we recommend that software use alternative mitigations (such as BHI_DIS_S) on future processors, since the sequences in this section may not be sufficient on all future processors due to potential future microarchitectural changes.

      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. 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: 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 sequence is effective on all current processors with Intel TSX support but, due to potential microarchitectural changes, may not guaranteed to work on all future processors that support Intel TSX. 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: 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 software 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 parts 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 should still use the software BHB-clearing sequence that is appropriate for the processor CPUID Family/Model that is enumerated to the guest.

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 may use a BHB-clearing sequence specific to the CPUID family/model/stepping shown to the guest.

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 BHB-clearing sequence may not be effective. 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 that enumerates the CPUID family/model/stepping of the Ice Lake processors to the guest, 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. 

VMM Support for Retpoline

VMMs should virtualize MSR reads of MSR_VIRTUAL_MITIGATION_ENUM such that bit 1 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. 

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.

Table 1: New IA32_SPEC_CTRL controls
Register Address Hex Register Address Dec Register Name / Bit Fields Bit Description Comment
48H 72 IA32_SPEC_CTRL Speculation Control (R/W) If any one of the enumeration conditions for the defined bit field positions holds.
48H 72 3 IPRED_DIS_U When 1, enable IPRED_DIS control for CPL3. Refer to the Intra-mode BTI section.
Enumerated by CPUID.7.2.EDX[IPRED_CTRL] (bit 1).
48H 72 4 IPRED_DIS_S When 1, enable IPRED_DIS control for CPL0/1/2. Refer to the Intra-mode BTI section.
Enumerated by CPUID.7.2.EDX[IPRED_CTRL] (bit 1).
48H 72 5 RRSBA_DIS_U When 1, disable RRSBA behavior for CPL3. Refer to the Retpoline section.
Enumerated by CPUID.7.2.EDX[RRSBA_CTRL] (bit 2). 
48H 72 6 RRSBA_DIS_S When 1, disable RRSBA behavior for CPL0/1/2. Refer to the Retpoline section.
Enumerated by CPUID.7.2.EDX[RRSBA_CTRL] (bit 2). 
48H 72 10 BHI_DIS_S When 1, enable BHI_DIS_S behavior. Refer to the Indirect Branch Predictor Controls section.
Enumerated by CPUID.7.2.EDX[BHI_CTRL] (bit 4). 

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.

Table 2: New IA32_ARCH_CAPABILITIES Controls
Register Address Hex Register Address Dec Register Name / Bit Fields Bit Description Comment
10AH 266 IA32_ARCH_CAPABILITIES Enumeration of Architectural Features (RO) If CPUID.(EAX-07H, ECX=0):EDX[29]=1
10AH 266 19 RRSBA A value of 1 indicates processor may have the RRSBA alternate prediction behavior, if not disabled by RRSBA_DIS_U or RRSBA_DIS_S.
10AH 266 20 BHI_NO A value of 1 indicates BHI_NO branch prediction behavior, regardless of the value of IA32_SPEC_CTRL[BHI_DIS_S] MSR bit.

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. 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.

Table 3: New Intel-defined Virtual MSRs for Software Mitigations
MSR Address / Bit Field Field Name Comments
MSR_VIRTUAL_
ENUMERATION
0x50000000   Read-only. Only available when bit 63 is set in IA32_ARCH_CAPABILITIES.
Not usable in VMX MSR lists.
  Bit 0 MITIGATION_CTRL_SUPPORT Enumerates VMM support for MSR_VIRTUAL_
MITIGATION_ENUM and MSR_VIRTUAL_
MITIGATION_CTRL.
  Bit 63:1 Reserved Reserved for future use.
MSR_VIRTUAL_
MITIGATION_ENUM
0x50000001   Read-only. Only available if MITIGATION_CTRL_
SUPPORT is enumerated.
Not usable in VMX MSR lists.
  Bit 0 BHB_CLEAR_SEQ_S_SUPPORT Enumerates VMM support for BHB_CLEAR_SEQ_S_USED.
  Bit 1 RETPOLINE_S_SUPPORT Enumerates VMM support for RETPOLINE_S_USED.
  Bit 63:2 Reserved Reserved for future use.
MSR_VIRTUAL_
MITIGATION_CTRL
0x50000002   Read/write. Only available if MITIGATION_CTRL_
SUPPORT is enumerated. Thread scope. Reset value of 0.
Not usable in VMX MSR lists.
  Bit 0 BHB_CLEAR_SEQ_S_USED Refer to Software Mitigations in Migration Pools. 
  Bit 1 RETPOLINE_S_USED Refer to Software Mitigations in Migration Pools. 
  Bit 63:2   Reserved for future use.

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 Sequencing 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 newer 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 

Table 4: Processors Affected by Incomplete Upper Target Isolattion
Processor Stepping (all unless otherwise noted) Code Names / Microarchitectures Product Family Brand Names

Branch History Injection (BHI)

CVE-2022-0001 
INTEL-SA-00598

Intra-Mode BTI

CVE-2022-0002 INTEL-SA-00598

06_7AH 1 Gemini Lake 1. Intel® Pentium® Processor Silver Series
2. Intel® Celeron® Processor J Series
3. Intel® Celeron® Processor N Series
1. Intel® Pentium® Processor Silver Series J5005, N5000
2. Intel® Pentium® Silver Processor J5005, N5000 
Intel® Celeron® Processor J4005, J4105
3. Intel® Celeron® Processor N4000, N4100
Software Software
06_7AH 8 Gemini Lake 1. Intel® Celeron® Processor J Series
2. Intel® Celeron® Processor N Series
1. Intel® Pentium® Silver J5040 Processor
Intel® Celeron® Processor J4025
Intel® Celeron® Processor J4125
2. Intel® Pentium® Silver N5030 Processor
Intel® Celeron® Processor N4020
Intel® Celeron® Processor N4120
Software Software
06_86H 4 Snowridge (Tremont) Intel® Atom® Processors Intel® Atom® Processor P5942B, P5931B, P5962B, P5921B Software Software
06_86H 5 (B step) Snowridge  (Tremont) Intel® Xeon® D processor family Intel® Xeon® D 1700, D2700 Software Software
06_86H 7 (C step) Snowridge  (Tremont) Intel® Xeon® D processor family Intel® Xeon® D 1700, D2700 Software Software
06_8AH 1 Lakefield B-step (Tremont) Intel® Core™ Processors with Intel® Hybrid Technology Intel® Core™ Processor i3-L13G4, i5-L16G7 Software Software
06_96H 1 Elkhart Lake (Tremont) Intel® Atom® Processors Intel Pentium Processor J6425, N6415, Intel Celeron Processor J6413, N6211. Intel Atom Processor x6413E, x6425RE, x6427FE, x6212RE, x6200FE, x6211E, x6425E Software Software
06_97H 2 Alder Lake S 12th Generation Intel® Core™ Processor Family Intel® Core™ Processor i9-12900K, i9-12900KF, i7-12700K, i7-12700KF, i5-12600K, i5-12600KF, i9-12900, i9-12900F, i7-12700, i7-12700F, i5-12400, i5-12400F, i9-12900T, i7-12700T MCU+Software MCU+Software
06_97H 5 Alder Lake S 12th Generation Intel® Core™ Processor Family
Intel® Pentium® Gold Processor Family
Intel® Celeron® Processor Family
Intel® Core™ Processor i5-12600, i5-12500, i5-12400, i5-12400F, i3-12300, i3-12100, i3-12100F, i5-12600T, i5-12500T, i5-12400T, i3-12300T, i3-12100T
Intel® Pentium® Gold Processor G7400, G7400T
Intel® Celeron® Processor G6900, G6900T
 
MCU+Software MCU+Software
06_9AH 3 1. Alder Lake H 2. Alder Lake P 1. 12th Generation Intel® Core™ Processor Family
2. 12th Generation Intel® Core™ Processor Family
1. Intel® Core™ Processor i9-12900H, i9-12900HK, i7-12800H, i7-12700H, i7-12650H, i5-12600H, i5-12500H, i5-12450H
2. Intel® Core™ Processor i7-1280P, i7-1270P, i7-1260P, i5-1250P, i5-1240P, (i3-1220P) 
 
MCU+Software MCU+Software
06_9CH 0 Jasper Lake (Tremont) Intel® Atom® Processors Intel® Pentium® Silver N6005, N6000 Processors
Intel® Celeron® Processor N4505, N4500, N5105, N5100
Software Software

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.

Table 5: Processors That Require MCU for Retpoline Performance Improvement
Processor Stepping (all unless otherwise noted) Code Names / Microarchitectures Product Family Brand Names
06_6AH 4, 5, 6 Ice Lake Xeon-SP 3rd Gen Intel® Xeon® Scalable processor family Intel® Xeon® Platinum 8300 processors, Intel® Xeon® Gold 6300 processors,  Intel® Xeon® Gold 5300 processors,  Intel® Xeon® Silver 4300 processors
06_6CH 1 Ice Lake D Intel® Xeon® D Processor Intel® Xeon® D-1513N, D-1518, D-1520, D-1521, D-1523N, D-1524N, D-1527, D-1528, D-1529, D-1531, D-1533N, D-1537, D-1539, D-1540, D-1541, D-1543N, D-1548, D-1553N, D-1557, D-1559, D-1563N, D-1564N, D-1567, D-1571, D-1573N, D-1577, D-1581, D-1587, D-1602, D-1612, D-1622, D-1623N, D-1627, D-1632, D-1633N, D-1637, D-1649N, D-1653N, D-1702, D-1712TR, D-1713NT, D-1713NTE, D-1714, D-1715TER, D-1718T, D-1722NE, D-1726, D-1732TE, D-1733NT, D-1734NT, D-1735TR, D-1736, D-1736NT, D-1739, D-1746TER, D-1747NTE, D-1748TE, D-1749NT, D-2123IT, D-2141I, D-2142IT, D-2143IT, D-2145NT, D-2146NT, D-2161I, D-2163IT,  D-2166NT, D-2173IT, D-2177NT, D-2183IT, D-2187NT, D-2191, D-2712T, D-2733NT, D-2738, D-2745NX, D-2752NTE, D-2752TER, D-2753NT, D-2757NX, D-2766NT, D-2775TE, D-2776NT, D-2777NX, D-2779, D-2786NTE, D-2795NT, D-2796NT, D-2796TE, D-2798NT, D-2798NX, D-2799 processors
06_7EH 5 Ice Lake U,Y 10th Generation Intel® Core™ Processor Family 10th Generation Intel® Core™ Processor Family
06_8AH 1 Lakefield B-step (Tremont) Intel® Core™ Processors with Intel® Hybrid Technology Intel® Core™ Processor i3-L13G4, i5-L16G7
06_8AH 1 Lakefield B-step (Sunnycove) Intel® Core™ Processors with Intel® Hybrid Technology Intel Core i3-L13G4, i5-L16G7
06_8CH 1 Tiger Lake U 11th Generation Intel® Core™ Processor Family Intel® Core™ i7-1185G7, i7-1165G7,  i7-1180G7, i7-1160G7, i5-1145G7,  i5-1140G7, i5-1130G7, i3-1125G4, i3-1120G4, i3-1110G4, Intel® Pentium® Gold 7505, Intel® Celeron® 6305
 
06_8CH 1 Tiger Lake U 11th Generation Intel® Core™ Processor Family Intel® Core™  i7-1185GRE, i7-1185G7E, i5-1145GRE, i5-1145G7E,  i3-1115GRE, i3-1115G4E
Intel® Celeron® 6305E  Processor
06_8CH 2 1. Tiger Lake U Refresh  
2. Tiger Lake H35
11th Generation Intel® Core™ Processor Family 1. Intel® Core™ i7-1195G7, i5-1155G7, i5-1135G7, i5-1156G7, i3-1132G4, i3-1115G4
2. Intel® Core™ i7-11390H, i5-11320H, Intel® Pentium® Gold 7505 
06_8DH     1 Tiger Lake H   1. 11th Generation Intel® Core™ Processor Family
2. Intel® Xeon® Processor Family
1. Intel® Core™ i9-11980HK, i9-11950H, i9-11900H, i7-11850H,  i7-11800H, i5-11500H, i5-11400H, i5-11260H, i7-11390H, i7-11375H, i7-11370H, i5-11320H, i5-11300H
2. Intel® Xeon® W-11955M, Intel® Xeon® W-11855M
 
06_8DH     1 Tiger Lake H   1. 11th Generation Intel® Core™ Processor Family
2. Intel® Xeon® Processor Family
1. Intel® Core™ i7-11850HE, i3-11100HE
2. Intel® Xeon®  W-11865MRE, W-11555MRE, W-11155MRE, W-11555MLE, W-11865MLE, W-11155MLE, Intel®
Celeron®6600HE
06_A7H 1 Rocket Lake 1. 11th Generation Intel® Core™ Processor Family
2. Intel® Xeon® E-2300 processor family
1. Intel® Core™ Processor i9-11900K, i9-11900KF, i9-11900, i9-11900T, i9-11900F, i7-11700K, i7-11700KF, i7-11700, i7-11700T, i7-11700F, i5-11600K, i5-11600KF, i5-11600, i5-11600T, i5-11500, i5-11500T, i5-11400, i5-11400F, i5-11400T
2. Intel® Xeon®E-2388G, E-2378G, E-2378, E-2386G, E-2356G, E-2336, E-2374G, E-2334, E-2324G, E-2314, E-2378G, E-2378, E-2386G, E-2356G, E-2336, E-2374G, E-2334, E-2324G, E-2314 processors
 

References

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.