Fact-checked by Grok 2 weeks ago

IBPB

The Indirect Branch Prediction Barrier (IBPB) is a hardware-based security feature implemented in modern x86 processors by Intel and AMD to mitigate speculative execution vulnerabilities, particularly Spectre Variant 2 (branch target injection), by invalidating indirect branch predictions after the barrier is invoked, thereby preventing malicious code from controlling branch targets in subsequent execution contexts.^[1]^[2] Introduced in response to the 2018 disclosure of Spectre attacks, IBPB operates by flushing the indirect branch predictor upon execution of a specific instruction or via a model-specific register (MSR) write, ensuring that software running before the barrier cannot influence predictions for code executed afterward, which is crucial for protecting against cross-process or cross-privilege-level attacks.^[3]^[4] This mechanism complements other mitigations like Indirect Branch Restricted Speculation (IBRS) but provides a more lightweight option for scenarios requiring frequent context switches, such as in virtualized environments or operating system kernels, though it incurs a performance overhead due to predictor flushing.^[2]^[5] Support for IBPB was added to AMD processors starting with microcode updates for Ryzen (Zen 1) in 2018 and is enumerated via vendor-specific CPUID extended feature flags (Intel: leaf 7, sub-leaf 0, EDX bit 26; AMD: function 8000_0008h, EBX bit 12), with ongoing refinements in Linux kernel implementations to optimize its use across processor generations, including 2025 updates for vulnerabilities like Indirect Target Selection and VMScape.^[1]^[4]^[6]^[7]

Overview

Definition and Purpose

The Indirect Branch Predictor Barrier (IBPB) is a hardware-based control mechanism implemented in x86 processors to manage speculative execution by isolating the state of the indirect branch predictor across security boundaries.^[1]^[2] Indirect branches, such as indirect jumps, calls, or returns, are instructions where the target address is determined at runtime—often stored in a register or memory—rather than being a fixed immediate value; these rely on the processor's indirect branch predictor tables to anticipate targets and maintain performance by reducing execution stalls.^[1]^[2] The primary purpose of IBPB is to mitigate branch target injection attacks, particularly Spectre Variant 2, by ensuring that indirect branches executed after the barrier do not leverage predictions "poisoned" by untrusted code from previous execution contexts on the same logical processor.^[1]^[2] Upon activation—typically via a write to a specific model-specific register (MSR), such as IA32_PRED_CMD on Intel or PRED_CMD on AMD—IBPB flushes or invalidates the indirect branch predictor state, clearing influences from prior branches without affecting direct branch predictions or other predictor components.^[1]^[2] A key concept of IBPB is that it functions as a targeted "prediction barrier," restricting speculation solely for indirect branches post-barrier while preserving overall predictor efficiency, in contrast to broader mechanisms like Indirect Branch Restricted Speculation (IBRS), which operate in a persistent mode and may impose higher performance overhead by limiting predictions across privilege levels.^[1] This design allows IBPB to be invoked on-demand during context switches or transitions between trusted and untrusted code, such as user-to-kernel or guest-to-host in virtualized environments, without requiring a full branch predictor flush.^[1]^[2]

Historical Context

The disclosure of the Spectre and Meltdown vulnerabilities in early January 2018, stemming from speculative execution flaws in modern processors, prompted rapid development of hardware mitigations.^[8] Intel introduced the Indirect Branch Predictor Barrier (IBPB) in January 2018 as part of microcode updates to counter these threats, specifically targeting branch target injection attacks.^[9] These updates were rolled out to address the immediate risks identified in coordinated vulnerability disclosures.^[10] IBPB was created primarily to mitigate CVE-2017-5715, known as Spectre Variant 2 (Branch Target Injection), which exploits indirect branch predictors to leak sensitive data across security boundaries. By inserting a barrier that flushes or isolates the indirect branch predictor state, IBPB prevents poisoned predictions from influencing subsequent code execution.^[9] AMD followed suit shortly thereafter, incorporating IBPB into microcode updates for its processors around the same period to align with industry-wide responses to the vulnerability.^[2] Initial deployment of IBPB occurred via firmware and microcode for Intel's 6th-generation Core processors (Skylake architecture) and subsequent generations, enabling broader compatibility without requiring new silicon.^[9] For AMD, support was added starting with the Ryzen (Zen) architecture in 2018 through similar microcode mechanisms, ensuring mitigation across affected x86 platforms.^[2] Ongoing refinements to IBPB have addressed emerging interactions with other predictor components, as evidenced by AMD's 2022 security bulletin AMD-SB-1040, which detailed potential vulnerabilities involving IBPB and return stack buffer predictions, leading to updated software mitigation guidance, emphasizing additional protections for the return address predictor, such as return stack buffer (RSB) filling techniques.^[11] Subsequent research in 2024 and 2025, including analyses of post-IBPB Spectre attacks and new flaws like VMScape (CVE-2025-40300), has continued to highlight interactions with branch predictors, prompting further refinements in software and microcode mitigations across Intel and AMD platforms as of November 2025.^[12]^[13]^[14] This evolution underscores the continued adaptation of IBPB in response to sophisticated speculative execution exploits.

Technical Mechanism

Branch Prediction Basics

Branch prediction is a fundamental technique in modern pipelined processors designed to mitigate the performance penalties associated with control-flow instructions, such as conditional branches and indirect jumps. These instructions disrupt the sequential flow of execution, potentially stalling the pipeline until the branch outcome—whether taken or not taken—and, in the case of indirect branches, the target address are resolved. By speculatively predicting these outcomes early in the pipeline, processors can continue fetching and executing instructions without interruption, thereby maintaining high instruction throughput.^[15] Indirect branches pose particular challenges for prediction due to their variable targets, which depend on runtime conditions like computed addresses or register values, unlike direct branches with fixed offsets. Modern CPUs address this by employing specialized indirect branch predictors that store and reuse recent target addresses based on branch history patterns, achieving high accuracy for recurring control transfers in workloads such as virtual function calls or switch statements. These predictors typically integrate with broader branch direction prediction mechanisms to forecast both the branch decision and the destination.^[16] Branch prediction enables speculative execution, where the processor out-of-order executes instructions along the predicted path while verifying the speculation later; correct predictions yield seamless performance, but mispredictions incur costly pipeline flushes. In secure contexts, adversaries can exploit this by poisoning predictor entries with misleading history, inducing speculative execution of unintended code paths that leak sensitive data through microarchitectural side channels, such as cache timing variations. Key components of branch prediction hardware include the Branch Target Buffer (BTB), a cache-like structure indexed by the branch instruction's program counter (PC) that holds predicted target addresses for both direct and indirect branches, allowing rapid lookup during instruction fetch. The Return Stack Buffer (RSB), a dedicated last-in-first-out (LIFO) stack, specifically predicts targets for return instructions by pushing call-site return addresses and popping them on returns, improving accuracy for nested function calls. Indirect predictor tables, often implemented as multi-way associative arrays or history-based structures like the Indirect Target Table (ITT), extend the BTB for complex indirect branches by associating multiple possible targets with branch history patterns to select the most likely one.^[16] Mechanisms such as the Indirect Branch Predictor Barrier (IBPB) serve as a brief reference point, acting as a speculation barrier that resets these predictor structures to prevent cross-context pollution.

IBPB Operation

The Indirect Branch Predictor Barrier (IBPB) is activated by writing a value of 1 to bit 0 of the PRED_CMD model-specific register (MSR 0x49), typically using the WRMSR instruction. This MSR is write-only, meaning that subsequent reads or writes to other bits (beyond bit 0) will trigger a general protection fault, ensuring that the barrier acts as a one-time serialization event in the CPU pipeline without requiring bit clearance.^[1]^[2] Upon execution, IBPB invalidates all entries in the indirect branch predictor and associated structures, such as flushing relevant entries in the Branch Target Buffer (BTB) specifically for indirect branches like near indirect calls and jumps, and the Return Stack Buffer (RSB) where supported (e.g., all Intel processors and AMD Zen 4 and later). On older AMD processors, IBPB does not flush the RSB, requiring additional mitigations such as RSB stuffing or specific flushes. This prevents the carryover of speculative predictions derived from previously executed code on the same logical processor, effectively clearing historical branch targets that could influence future speculation. The operation targets only indirect branch predictions, leaving direct branch predictions unaffected.^[1]^[2]^[17] As a barrier mechanism, IBPB ensures that any indirect branch encountered after its activation begins speculation from an empty or default predictor state, thereby blocking potential cross-context attacks where malicious code poisons predictions for subsequent trusted execution contexts. This serialization point in the pipeline serializes instruction execution momentarily to enforce the flush, but it does not impact the overall flow of direct branches or non-branch instructions. Implementation details vary by processor generation and vendor; for example, a October 2024 Linux kernel update addressed IBPB behavior on older AMD CPUs, and Intel provided microcode refinements for indirect target selection as of May 2025. Support for IBPB is enumerated via CPUID leaf 7, EDX bit 26 on Intel processors or CPUID function 8000_0008, EBX bit 12 on AMD processors.^[1]^[2]^[5]^[6]

Processor Implementations

Intel Support

Indirect Branch Predictor Barrier (IBPB) support was introduced by Intel in early 2018 through microcode updates for processors that already supported Indirect Branch Restricted Speculation (IBRS), beginning with the Skylake microarchitecture (6th generation Core processors) and extending to subsequent generations.^[18]^[19] These updates were part of broader mitigations against Spectre Variant 2 (CVE-2018-3653), enabling IBPB to address indirect branch target predictions within the same privilege level.^[9] Feature detection for IBPB on Intel processors is performed using the CPUID instruction with leaf 07H (EAX=07H, ECX=0), where bit 26 of EDX (Spec Ctrl) set to 1 indicates support for both IBRS and IBPB.^[20]^[19] However, enabling IBPB requires explicit activation by the operating system kernel or virtual machine monitor via the IA32_PRED_CMD Model-Specific Register (MSR) (address 0x49), by writing 1 to bit 0, as it is not automatically enabled at the hardware level.^[20] In Intel implementations, IBPB operates by writing 1 to bit 0 of the IA32_PRED_CMD MSR (0x49), which establishes a prediction barrier that flushes the indirect branch predictor while preserving direct branch prediction history to minimize performance overhead.^[19] It can be deployed standalone for intra-privilege isolation or in combination with IBRS for cross-privilege protection and Single Thread Indirect Branch Predictors (STIBP) for hyper-threaded scenarios, allowing flexible mitigation strategies without fully restricting speculation modes.^[18]^[19] Post-2018 enhancements to IBPB were integrated starting with the Ice Lake microarchitecture (10th generation Core processors), including improved hardware support for enhanced IBRS (eIBRS) that reduces the need for frequent IBPB invocations in certain workloads.^[9] Additionally, microcode updates from this period onward ensure the indirect branch predictor is flushed upon entry to Intel Software Guard Extensions (SGX) enclaves, enhancing enclave isolation against indirect branch attacks without software intervention.^[6] These improvements continued in later generations like Tiger Lake and beyond, focusing on tighter coupling with confidential computing features for better security and efficiency. As of 2025, further research has highlighted potential bypasses of IBPB in privileged contexts, prompting additional kernel optimizations in Linux 6.13 for enhanced barrier enforcement on newer hybrid CPU designs.^[6]^[21]

AMD Support

AMD introduced support for the Indirect Branch Predictor Barrier (IBPB) through microcode updates released in January 2018, initially targeting Zen-based processors such as first-generation Ryzen CPUs and EPYC server chips to mitigate Spectre Variant 2 attacks.^[22] These updates enabled IBPB functionality via software control on existing hardware, providing an essential barrier against indirect branch target injection without requiring new silicon.^[2] Full hardware-level integration of IBPB arrived with the Zen 2 microarchitecture in 2019, enhancing performance and reliability of the barrier mechanism in processors like Ryzen 3000 series and second-generation EPYC.^[23] Detection of IBPB support on AMD processors follows the same Model-Specific Register (MSR) interface as Intel, using MSR 0x49 (PRED_CMD) where bit 0 activates the barrier upon write.^[2] However, AMD implementations exhibit specific behaviors, including general protection (GP) faults triggered by attempts to read from MSR 0x49, enforcing its write-only nature to prevent unintended disclosures.^[2] Software can query availability via CPUID function 8000_0008H, where bit 12 in EBX indicates IBPB support in extended feature enumeration.^[24] A distinctive aspect of AMD's IBPB is its interaction with the Return Stack Buffer (RSB), which can limit protection against return-oriented predictions; for instance, in the AMD-SB-1040 vulnerability disclosed in 2022, reliance solely on IBPB failed to fully flush the RSB, potentially enabling information leakage via speculative returns (CVE-2022-23824).^[11] To address such gaps, AMD recommends pairing IBPB with serialization instructions like LFENCE to establish robust prediction barriers, particularly in cross-process or virtualized environments.^[25] In response to ongoing vulnerabilities like Retbleed, the Linux kernel version 6.12 incorporated patches in October 2024 to improve IBPB handling specifically for older AMD CPUs, including Zen 3 and prior generations, ensuring more effective mitigation without excessive performance overhead.^[5] These updates refine barrier invocation during context switches, bolstering defenses against speculative execution attacks on legacy hardware.^[5]

Security Mitigations

Role in Spectre Variant 2

Spectre Variant 2, also known as branch target injection (CVE-2017-5715), exploits indirect branch predictors in modern processors to redirect speculative execution toward malicious code gadgets, enabling data leakage through cache side channels such as timing attacks on victim data.^[26] The attack poisons the indirect branch predictor with attacker-controlled branch targets during untrusted code execution, allowing subsequent trusted code—such as kernel or enclave routines—to speculatively follow these tainted predictions and inadvertently access sensitive information before misprediction resolution.^[9] The Indirect Branch Predictor Barrier (IBPB) serves as a key hardware mitigation specifically targeting this vulnerability by establishing a predictive barrier that clears or invalidates entries in the indirect branch predictor, preventing prior software from influencing the targets of subsequent indirect branches on the same logical processor.^[9] In practice, IBPB operates by writing to a control MSR (e.g., IA32_PRED_CMD bit 0 on Intel platforms or PRED_CMD bit 0 on AMD), which resets the predictor state to neutralize any poisoned entries accumulated from attacker code.^[2] This mechanism is particularly effective in isolating speculative behavior across security boundaries, ensuring that untrusted user-mode code cannot manipulate predictions for privileged kernel-mode execution.^[26] IBPB is typically invoked during context switches, such as transitions from user to kernel mode or between virtual machines, to enforce process isolation without disabling speculation entirely, thereby preserving performance in multi-tenant environments like operating systems and hypervisors.^[9] For instance, operating systems like Linux and Windows deploy IBPB on privilege-level changes to block cross-process branch target injection, a scenario critical for preventing intra-mode attacks where an attacker process poisons predictors that persist into the victim's execution context.^[2] While IBPB significantly reduces the attack surface by invalidating tainted predictor entries and limiting the window for exploitation, it does not provide standalone protection against all Spectre Variant 2 vectors and is most effective when combined with software techniques like retpoline for indirect branch handling in performance-critical code paths.^[26] Its deployment requires CPU support (verifiable via CPUID on Intel or equivalent on AMD) and microcode updates, with empirical evaluations showing it curbs successful branch target injections in controlled tests by resetting predictor history.^[9]

Limitations and Complementary Features

Indirect Branch Predictor Barrier (IBPB) primarily mitigates indirect branch prediction poisoning in Spectre Variant 2 attacks but does not protect against direct branch poisoning, where attackers manipulate branch targets without relying on speculative prediction state, or return-oriented attacks that exploit the Return Stack Buffer (RSB), necessitating complementary techniques like RSB stuffing to clear or overwrite return predictions.^[17] IBPB is also ineffective if not invoked on every context switch between security domains, as residual predictor state from untrusted code can persist and enable cross-context leakage.^[4] Additionally, frequent invocation introduces notable performance overhead, with barriers consuming approximately 10,000 cycles on AMD Zen processors and 2,500 cycles on later generations, impacting system throughput in high-context-switch environments.^[27] IBPB integrates with other hardware mechanisms for layered defense, including Indirect Branch Restricted Speculation (IBRS), which restricts speculative execution of indirect branches to the current privilege level, preventing lower-privilege code from influencing higher-privilege predictions.^[3] It also pairs with Single Thread Indirect Branch Predictors (STIBP), which isolates indirect branch predictions to the current logical processor, blocking intra-core cross-thread attacks even when hyper-threading is active.^[2] Together, these features—along with software-based single-thread indirect branch predictors—form a multi-tiered approach to containing branch target injection across privilege boundaries and threads.^[4] Despite these integrations, vulnerabilities have exposed gaps in IBPB's implementation; for instance, the 2024 Indirector attack on Intel processors exploits interactions between the Branch Target Buffer (BTB) and Indirect Branch Predictor (IBP), allowing high-precision target injection that bypasses IBPB barriers through reverse-engineered predictor structures.^[28] On AMD systems, a 2022 flaw revealed that IBPB did not fully flush the RSB on processors prior to Zen 4, enabling potential leakage via poisoned return predictions when relying on the barrier for isolation.^[11] To address such constraints, operating system kernels are advised to enable IBPB selectively—such as on VM exits in cloud environments or via per-task opt-in—tailoring deployment to specific threat models while minimizing performance penalties.^[11]^[17] As of 2025, ongoing research has identified further limitations. The VMScape vulnerability (CVE-2025-40300), disclosed in September 2025, exploits speculative execution in Linux kernel virtualization to leak data across VM boundaries; mitigations include enabling IBPB on VM exits to isolate predictor states.^[29] Additionally, the Branch Privilege Injection attack, presented at USENIX Security 2025, demonstrates compromises to Spectre Variant 2 hardware mitigations, including IBPB, by associating predictions with privilege domains in ways that allow cross-domain poisoning, underscoring the need for updated microcode and kernel configurations.^[30]

Software and Usage

Operating System Integration

In the Linux kernel, support for Indirect Branch Predictor Barrier (IBPB) as a mitigation for Spectre variant 2 has been integrated since version 4.15, where it is automatically enabled on supported hardware during context switches to enhance inter-process isolation by flushing indirect branch predictors.^[31]^[4] Userspace applications can control IBPB activation per process using the prctl() system call with PR_SET_SPECULATION_CTRL, allowing fine-grained enabling of indirect branch speculation protections.^[32] Patches merged into Linux kernel 6.12 in October 2024 address IBPB handling issues specific to older AMD processors, improving reliability in Retbleed mitigation scenarios.^[5] Microsoft integrated Spectre variant 2 mitigations into the Windows kernel starting with 2018 security updates such as KB4078407 for Windows 10 versions 1607, 1703, and 1709, as well as Windows Server 2016.^[33] The kernel performs CPUID checks at boot to detect support for relevant hardware features and activates mitigations against branch target injection across processes.^[34] FreeBSD enables IBPB on Intel processors supporting the feature through kernel boot-time detection of CPU capabilities, such as via the Structured Extended Features3 CPUID leaf, with activation tied to microcode updates for Spectre variant 2 mitigation and process isolation.^[35] Similarly, macOS, leveraging the XNU kernel, provides mitigations against Spectre variant 2 as part of security updates released since 2018, including macOS Mojave 10.14.5 and later, following boot-time hardware enumeration.^[36] OpenBSD has supported IBPB since version 6.3 (2018) for compatible processors, configurable via sysctl hw.spec_store_bypass_disable.^[37] IBPB enablement across these operating systems is typically automatic upon detection of hardware support, though configurable via kernel boot parameters—for instance, the nospectre_v2 option in Linux disables variant 2 mitigations including IBPB to accommodate performance-sensitive workloads.^[38] This automatic approach balances security with the inherent performance overhead of barrier insertions.

Performance Implications

Each invocation of the Indirect Branch Predictor Barrier (IBPB) flushes the indirect branch predictor, incurring a penalty from mispredictions on subsequent indirect branches until the predictor repopulates, which can lead to 1-5% slowdowns in branch-intensive workloads.^[39] This overhead arises primarily during privilege level transitions, such as context switches, where the barrier prevents cross-domain predictor poisoning but temporarily degrades prediction accuracy for the new execution domain.^[40] Benchmarks indicate a global performance impact of approximately 2-3% in server environments characterized by frequent context switches, as measured on modern Intel processors like Cascade Lake and Ice Lake using OS-intensive workloads from LEBench.^[40] In contrast, single-threaded tasks experience lower overhead, often below 2%, due to reduced invocation frequency.^[40] These figures reflect hardware-optimized implementations, where cycle costs for IBPB have decreased to around 300-800 cycles per invocation on recent CPUs.^[40] To mitigate these costs, IBPB is deployed selectively, such as only during user-to-kernel transitions, rather than continuously.^[1] It is often combined with software-based retpolines, which replace indirect branches with prediction-resistant gadgets, reducing reliance on frequent hardware barriers while maintaining security.^[39] In multi-tenant systems like cloud servers, IBPB remains essential to isolate untrusted processes and prevent branch target injection attacks, justifying the modest overhead for enhanced security.^[1] However, in trusted single-tenant environments, it can be disabled via kernel parameters to restore full throughput without compromising safety.^[1]

References

[1]
Indirect Branch Predictor Barrier - Intel
Jan 3, 2018 · The indirect branch predictor barrier (IBPB) is an indirect branch control mechanism that establishes a barrier, preventing software that executed before the ...
[2]
[PDF] AMD64 technology indirect branch control extension
IBPB. Indirect branch prediction barrier (IBPB) exists at MSR 0x49 (PRED_CMD) bit 0. This is a write only MSR that both. GP faults when software reads it or if ...
[3]
Speculative Execution Side Channel Mitigations - Intel
May 26, 2021 · Indirect Branch Predictor Barrier (IBPB): Prevents indirect branch predictions after the barrier from being controlled by software executed ...
[4]
Indirect Target Selection (ITS) - The Linux Kernel documentation
Indirect Branch Prediction Barrier (IBPB): After an IBPB, indirect branches may still be predicted with targets corresponding to direct branches executed ...
[5]
Linux Fixes Indirect Branch Predictor Barrier "IBPB" Handling For ...
Oct 18, 2024 · Merged today to Linux 6.12 Git were bug fixes to AMD's Indirect Branch Predictor Barrier (IBPB) handling that can be optionally used as part of the Retbleed ...
[6]
[PDF] Exploiting Speculative Execution - Spectre Attacks
Finally, Indirect Branch Predictor Barrier (IBPB), pre- vents software running before setting the barrier from affecting branch prediction by software ...
[7]
[PDF] Speculative Execution Side Channel Mitigations - Intel
The indirect branch predictor barrier (IBPB) is an indirect branch control mechanism that establishes a barrier, preventing software that executed before the ...
[8]
KB4073757: Protect Windows devices against silicon-based ...
In January 2018, Microsoft released information about a newly discovered class of hardware vulnerabilities (known as Spectre and Meltdown) that involve ...
[9]
IBPB and Return Stack Buffer Interactions - AMD
Nov 8, 2022 · AMD is aware of a potential vulnerability affecting AMD CPUs where the OS relies on IBPB to flush the return address predictor.Missing: introduction 2018
[10]
[PDF] A Study of Branch Prediction Strategies
A Study of Branch Prediction Strategies. James E. Smith. Control Data Corporation. Arden Hills, Minnesota. ABSTRACT. In high-performance computer systems ...
[11]
[PDF] Indirector: High-Precision Branch Target Injection Attacks Exploiting ...
Aug 14, 2024 · Mitigations from CPU Vendors: As discussed in Section 4, the Indirect Branch Prediction Barrier (IBPB) is the most strict defense available ...
[12]
Indirect Branch Restricted Speculation - Intel
Jan 3, 2018 · Indirect Branch Restricted Speculation (IBRS) is an indirect branch control mechanism that restricts speculation of indirect branches.
[13]
[PDF] Speculative Execution Side Channel Mitigations - kib.kiev.ua
Indirect Branch Predictor Barrier (IBPB): Prevents indirect branch predictions after the barrier from being controlled by software executed before the barrier.Missing: AMD | Show results with:AMD<|control11|><|separator|>
[14]
CPUID Enumeration and Architectural MSRs - Intel
May 12, 2025 · Enumeration of architectural model specific registers (MSRs) on Intel® processors used to help mitigate transient execution attacks.
[15]
Indirect Target Selection - Intel
May 12, 2025 · Indirect Branch Predictor Barrier (IBPB) Intel is providing a microcode update to ensure that indirect branches predicted after an indirect ...
[16]
AMD Confirms They are Affected by Spectre, too | TechPowerUp
Jan 12, 2018 · AMD will make optional microcode updates available to our customers and partners for Ryzen and EPYC processors starting this week. We expect to ...
[17]
[PDF] Technical Update Regarding Speculative Return Stack Overflow
Feb 25, 2024 · On AMD “Zen” and “Zen2” microarchitecture-based CPUs, the IBPB operation flushes branch type predictions from the branch predictor but does ...
[18]
Understanding Spectre v2 Mitigations on x86 | linux - Oracle Blogs
Apr 1, 2025 · IBPB is probably the most effective mitigation for Spectre v2 as it works for the JMP/CALL predictor and the RET predictor (although there are ...Missing: Ryzen | Show results with:Ryzen
[19]
[PDF] SOFTWARE TECHNIQUES FOR MANAGING SPECULATION ... - AMD
IBPB – Places a barrier such that indirect branch predictions from earlier execution cannot influence execution after the barrier. IBRS – Restricts indirect ...<|control11|><|separator|>
[20]
Branch Target Injection / CVE-2017-5715 / INTEL-SA-00088
Jan 3, 2018 · Indirect Branch Predictor Barrier (IBPB): Prevents indirect branch predictions after the barrier from being controlled by software executed ...
[21]
RSB-related mitigations - The Linux Kernel documentation
“The indirect branch predictor barrier (IBPB) is an indirect branch control mechanism that establishes a barrier, preventing software that executed before ...Missing: operation | Show results with:operation
[22]
Spectre Side Channels - The Linux Kernel documentation
All Spectre variant 2 mitigations can be forced on at boot time for all programs (See the “on” option in Mitigation control on the kernel command line). This ...Missing: limitations | Show results with:limitations
[23]
[PDF] Technical Guidance for Mitigating Branch Type Confusion - AMD
As discussed later in this paper, flushing the BTB structure with the Indirect Branch Prediction Barrier (IBPB) operation mitigates all forms of BTC and this ...
[24]
Indirector: High-Precision Branch Target Injection Attacks ... - USENIX
This paper introduces novel high-precision Branch Target Injection (BTI) attacks, leveraging the intricate structures of the Indirect Branch Predictor (IBP) ...Missing: vulnerability | Show results with:vulnerability
[25]
Meltdown/Spectre mitigation for 4.15 and beyond - LWN.net
Jan 15, 2018 · The 4.15 kernel will include a broad set of mitigations, while some others will have to wait for later; read on for details on where things stand.
[26]
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/branch-target-injection.html
[27]
Update to enable mitigation against Spectre, Variant 2
Summary. Applying this update will enable the Spectre Variant 2 mitigation CVE-2017-5715 - “Branch target injection vulnerability.”
[28]
SpeculativeExecutionVulnerabilit...
Feb 10, 2022 · The patches for retpoline approach to mitigation of the Spectre variant 2 vulnerability are in work, meantime we provide IBRS-based mitigation ...
[29]
Additional mitigations for speculative execution vulnerabilities in ...
Nov 5, 2023 · Apple has released security updates in macOS Mojave 10.14.5 to protect against speculative execution vulnerabilities in Intel CPUs.
[30]
The kernel's command-line parameters
This boot option prevents Linux from overwriting the CMCI threshold set by the bios. Without this option, Linux always sets the CMCI threshold to 1.
[31]
[PDF] Restoring the Performance of Indirect Branches In the Era of Spectre
Jul 10, 2019 · branches comes at a significant cost: in some benchmarks, we observe up to a 20% slowdown due to retpolines, making. Spectre variant 2 one of ...
[32]
Performance Evolution of Mitigating Transient Execution Attacks
Apr 5, 2022 · Across a range of benchmarks, we characterize the overhead caused by miti- gations on each CPU and further attribute how much of the overall ...