BiasScope: Exploiting Branch History

• BiasScope is a cross-privilege control flow side-channel attack that exploits inaccurate branch history management in processors.
• It manipulates the eviction of BST entries and incomplete updates in the Branch History Buffer to induce mispredictions and observable cache timing variations.
• Experimental results on ARM and AMD architectures highlight its effectiveness and emphasize the need for improved microarchitectural isolation and context-aware defenses.

BiasScope is a cross-privilege control flow side-channel attack targeting modern processors by exploiting the inaccurate management of branch history in hardware. It bypasses existing privilege separation in branch prediction resources, enabling attackers to infer fine-grained control flow decisions made by victim processes—including those of higher privilege levels such as kernel space—through manipulation and eviction of metadata associated with branch history. BiasScope reveals a fundamental vulnerability in speculative execution environments related to resource sharing and microarchitectural contention, specifically in Branch Prediction Units (BPUs) and the Branch History Buffer (BHB).

1. Principles and Mechanism

BiasScope operates by manipulating the filtering and eviction policies in hardware structures responsible for tracking branch outcomes—primarily the BHB and auxiliary tables such as the Branch Status Table (BST). BPUs rely on histories of branch decisions (taken/not-taken) to anticipate future branch directions; these histories are stored in the BHB and are used for predicting indirect branch targets prior to their resolution. Processors typically deploy filtering mechanisms to exclude "biased" branches (those whose outcomes seldom change) from contaminating the finite BHB state. BiasScope disrupts this logic by adversarially triggering BST evictions, selectively removing or preventing updates for certain branches, which results in the BHB carrying an incomplete or stale history.

Once a victim process executes a sequence of branches (denoted $BH[n]$ followed by a branch $B_x$), the adversary orchestrates conditions so that $B_x$’s entry is purged from the BST. Instead of the BHB reflecting the full, correct history $BHB(BH[n] \circ B_x)$, it is left as $BHB(BH[n])$. This missing information alters the BPU's prediction for subsequent indirect branch instructions, causing mis-speculation toward attacker-observable alternative targets.

2. Technical Details and Attack Flow

The technical operation of BiasScope is closely tied to the functioning of BPUs and the updating policy for BHBs:

• Branch History Buffer (BHB): Records the outcomes of recent branches. The sequence of branch outcomes determines the branch history fingerprint.
• Branch Status Table (BST): Auxiliary structure tracking which branches are "biased" and filtering their updates to the BHB.

BiasScope forces branch history inaccuracies via BST eviction. Under normal circumstances, each branch executed updates the history. If an attacker manages to evict the BST entry for $B_x$—for example, by generating collisions due to sharing aliases in the BST—then the update for $B_x$ is suppressed. This leads to scenarios where:

$BHB(BH[n] \circ B_x_{\text{evicted}}) = BHB(BH[n])$

The BPU then mispredicts the indirect branch (e.g., $Bi_{\text{pred}}$), yielding an observable side effect. Attackers can discern these mis-speculations by monitoring microarchitectural artifacts—most commonly, cache timing differences resulting from the mispredicted code path.

Representative Attack Flow Diagram (as described in the paper):

1. Flow A (baseline): Victim executes $BH[n]$ followed by $B_x$, yielding BHB with full history, correct indirect branch prediction to target $t_{\text{alternate}}$.
2. Flow B (attacked): Attacker has evicted $B_x$ record via BST manipulation, so victim's BHB only reflects $BH[n]$; prediction for indirect branch differs, landing on $t_{\text{primary}}$.

The attacker probes which target was speculatively executed by timing subsequent cache accesses, thus inferring whether $B_x$ was actually taken by the victim.

3. Experimental Results

BiasScope was experimentally demonstrated on several processor architectures, including ARM Cortex-A72/A76/A78 and AMD Zen4. The attack utilizes code patterns featuring a chain of branches ($BH[n]$) culminating in an indirect branch through $Bi_{\text{pred}}$. An adversary running at a lower privilege level deliberately evicts BST entries corresponding to the victim's branches, inducing exploitable changes in branch history.

By observing cache timing variations (resulting from different speculatively executed paths), the attacker achieved high success rates in leaking branch outcomes across privilege boundaries. On tested devices, the approach reliably produced misprediction events that resulted in measurable, leakable side-channel signals. These findings highlight the practical severity and generality of the vulnerability.

4. Security Implications

BiasScope expands the known attack surface of speculative and transient execution hardware. While prior mitigations focused on isolating branch target buffers across contexts (e.g., user/kernel), BiasScope reveals that residual shared state in branch history structures (BHB and BST) remains exploitable. Even hardened CPUs where branch targets are context-partitioned can leak control flow decisions if history management is not fully isolated.

This result underlines the inadequacy of earlier speculative execution defenses which neglected cross-context contamination of branch histories. BiasScope renders software-only approaches such as retpolines or simple fence instructions insufficient, as these do not address the fundamental sharing and eviction issues in BHB/BST structures.

For hardware designers, the implication is that both branch target and history management must incorporate strict domain isolation—ideally tracking process or privilege boundaries at the BHB/BST update level. For system software, sanitizing branch history state on transitions between privilege levels and enforcing context-aware flushing becomes necessary.

5. Mitigation Strategies

The paper details several mitigation avenues:

• BHB/BST Context Isolation: Update policies and storage should encode process or security domain context, ensuring that history and status cannot be evicted or contaminated across boundaries.
• Hardware Flushing: Resetting and sanitizing BHB and BST contents during context switches—e.g., kernel/user transition—prevents attackers from persisting cross-context interference.
• Software Techniques: Augment classical defenses (fences, retpolines) to explicitly flush or regenerate history structures where possible.
• Formal Verification and Partitioning: Future processor designs should be analyzed with respect to branch history isolation guarantees, using formal methods where feasible.

These approaches constitute a comprehensive mitigation plan against BiasScope and related history-based attacks.

6. Relation to Other Side-Channel Attacks

BiasScope is one of three attack primitives introduced by the authors, alongside Spectre-BSE and Spectre-BHS, all of which leverage different vulnerabilities in speculative execution tied to branch history manipulation and mis-speculation. Its distinguishing factor is the use of cross-privilege branch history contamination, rather than traditional attacks relying on mispredicted targets alone.

A demonstration tool, Chimera (based on eBPF), was developed to show a variant of Spectre-BHS which relies on the same core principles as BiasScope, leaking kernel memory contents at rates up to 24,628 bit/s.

7. Broader Impact

BiasScope’s exposé of cross-privilege vulnerabilities in branch history structures highlights the pressing need for hardware-centric mitigations in speculative execution environments. The methodology and experimental results necessitate reconsideration of architectural guarantees for security isolation, especially concerning microarchitectural resource sharing. Its findings are relevant to processor designers, system architects, operating system developers, and any stakeholder concerned with securing transient execution against cross-domain attacks.

BiasScope represents a paradigm shift in the understanding of side-channel attack surfaces, underscoring the dangers of incomplete microarchitectural isolation even when software and branch target mitigation strategies are in place (Zhu et al., 8 Jun 2025).