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.
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).
|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.
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_CTL[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_CTL[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.
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
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 code sample below is a proposed software BHB-clearing sequence for use after indirect branch prediction barriers (if deemed necessary for a particular threat model). Refer to the Branch History and Indirect Branch Prediction Barriers section for additional information.
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
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 220.127.116.11 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.
Product and Performance Information
Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.