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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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).
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 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.
|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).
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.
|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=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.
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.
|MSR||Address / Bit Field||Field Name||Comments|
|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_
|Bit 63:1||Reserved||Reserved for future use.|
|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.|
|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.|
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.
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.
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
|Processor||Stepping (all unless otherwise noted)||Code Names / Microarchitectures||Product Family||Brand Names||
Branch History Injection (BHI)
|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
|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
|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
|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)
|06_9CH||0||Jasper Lake (Tremont)||Intel® Atom® Processors||Intel® Pentium® Silver N6005, N6000 Processors
Intel® Celeron® Processor N4505, N4500, N5105, N5100
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.
|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®
|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
- 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*
Intra-mode BTI does not refer to indirect branch predictions using predictor entries which contain targets previously created for the same indirect branch.
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.
See section 188.8.131.52 in the Speculative Execution Side Channel Mitigations technical paper for more information on IBRS/eIBRS.
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.
Refer to the Branch History Injection and Intra-mode Branch Target Injection columns of the consolidated Affected Processors table.
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.
The behavior for those earlier implementations is described in section 18.3.8, “Constraining Speculation after Missing ENDBRANCH” of the Intel Software Developers Manual.