AI
Spectre’s Unfinished Business: How EIBRS Was Supposed to End It
In 2017, Intel called an emergency cross-industry meeting to address Spectre: a class of attacks that let user-space code read kernel memory by poisoning the branch target predictor. The root cause is that branch predictions are tagged by virtual address, so predictions from one privilege domain alias into another. Intel’s first fix was IBRS, which Linus Torvalds called “garbage” on the mailing list. The long-term answer was EIBRS, a hardware knob that tags predictions with a privilege mode so a user-space entry cannot mispredict a kernel branch. After enabling it, industry moved on.
The Race Condition: A Syscall That Shouldn’t Matter, Does
Spamming getpid syscalls anywhere in the attack sequence made the branch injection work. That pointed to a pipeline delay: on Intel processors, a branch execution does not instantly write to the predictor. It queues. The queue entry collects the target address, finds an eviction candidate, and locates a slot before storing the prediction. If a privilege switch happens while the entry is still in that queue, the processor tags it with the current privilege level rather than the original one. Put the syscall right after training the branch, and the queued prediction lands in the kernel-mode predictor.
BHIDS: Intel’s Own Mitigation Clears the Path
Intel CPUs use multiple branch predictors ranked by accuracy. The history-based predictor wins whenever it can. Only the lower-precedence, IP-based predictor was vulnerable to this attack. Getting the CPU to use the weaker one should have been hard. It wasn’t. Intel’s BHIDS feature, added to mitigate branch history injection, simply disables the history-based predictor in supervisor mode. That left the vulnerable predictor as the only option in the kernel.
“makes our attack really easy.” — Sandro Rüegge
Live Demo: /etc/shadow Leaked on a Patched 13th-Gen System
The target: a 13th-gen Intel Raptor Lake server running Ubuntu’s newest LTS at the time, with all mitigations enabled. From an unprivileged shell with no access to /etc/shadow and no sudo rights, the researchers ran the live /etc/shadow leak on Raptor Lake (22:41). The attack broke ASLR via branch predictor collisions, located the reload buffer and the shadow file in kernel memory, then leaked the root password hash. The full sequence completed in seconds.
Affected Range and the Microcode Black Box
The researchers traced the vulnerability back to the first Intel CPUs with in-silicon Spectre mitigations. Processors without EIBRS were also affected via the indirect branch prediction barrier (IBPB). Chips not yet launched at disclosure time were vulnerable too. Intel provided a microcode update that stopped the known proof-of-concept, but the fix is encrypted. The researchers cannot audit what it actually changes, and cannot rule out variants that survive it. The Spectre cat-and-mouse cycle has run since 2018.
“It’s been going on since 2018 at least.” — Johannes
Q&A
Given the age of speculative execution, is it time to move to architectures like Apple M1 that might not have these problems? Speculative execution is necessary for performance on every modern processor, so all architectures face similar issues; papers already cover Apple M1 vulnerabilities, and ARM processors show the same class of problems with more scattered mitigations across licensees. ▶ 28:27
Notable Quotes
attacking because it’s a lot more fun. Sandro Rüegge · ▶ 0:34
makes our attack really easy. Sandro Rüegge · ▶ 18:41
It’s been going on since 2018 at least. Johannes · ▶ 27:06
Key Takeaways
- A pipeline delay in Intel’s branch predictor lets user-space predictions survive a privilege switch, bypassing EIBRS.
- Intel’s BHIDS mitigation for branch history injection accidentally disables the competing predictor, simplifying the attack.
- Every Intel CPU with in-silicon Spectre mitigations is affected; a microcode update fixes the known PoC but cannot be audited.