Spectre on RISC-V Silicon

Fri, 03 Jul 2026 00:00:00 +0000

Our paper Spectre on RISC-V Silicon: Attacks and Defenses on Commercial Out-of-Order Processors has been accepted at USENIX Security ‘26.

Paper Artifact

This post is the short version of what we found.

RISC-V is an open, modular instruction set architecture that anyone can implement without a license fee. Many independent vendors build their own cores from it, ranging from tiny in-order microcontrollers to superscalar out-of-order designs.

For a long time, RISC-V had a reputation for being out of Spectre’s reach. That reputation was reasonable in 2018. Because the RISC-V silicon you could actually buy back then was in-order. Both the RISC-V Foundation and SiFive said so publicly at the time, and they were right about the hardware that existed. The problem is that the myth that RISC-V is somehow not affected by Spectre is quite persistent. Commercial out-of-order RISC-V cores now use the same kind of speculation that made Spectre relevant on x86 and ARM, while the software stack was never revisited. We wanted to know what that means for the RISC-V ecosystem.

1. Spectre Works on RISC-V Silicon

We evaluated the T-Head Xuantie C910/C920 and the SiFive P550. These were the only commercially available out-of-order RISC-V processors when we did the study. But there are many different out-of-order RISC-V processors coming out, and our work should make it easy to test them all. The takeaway from these experiments was that all Spectre variants that worked on x86 before also work on RISC-V, but sometimes with a few extra tricks. A notable exception is Spectre-BTB (v2), which does not work out of the box everywhere because whether the indirect branch predictor is enabled depends on the firmware. The C910 and P550 ship with it disabled, while our C920 had it enabled. Enabling it made the attack work but sometimes also crashed the machine, which hints at a hardware bug.

2. From BPF Gadget to File Contents

We also built an exploit for the paper that uses a Spectre gadget to read arbitrary files. We used BPF because it was the only feasible exploit path on the machines we had. Typically, kernel Spectre exploits use Spectre-BTB because it gives a lot of flexibility in gadget selection. The RISC-V cores we tested split the BTB between userspace and kernel, which makes these exploits hard.

The basic gadget comes from a missing fence in the RISC-V BPF JIT. Recent Linux kernels insert BPF_NOSPEC barriers when verifier-approved programs need a speculation barrier.¹ The RISC-V JIT emits nothing for BPF_NOSPEC, so the verifier considers the program protected while the generated code has no barrier at all.

The gadget itself is a speculative type confusion. We write BPF code where a branch decides what ends up in a register that gets dereferenced right after. One path puts a valid kernel pointer there, the other puts a scalar we control. Train the branch on the pointer path, then take the scalar path. Architecturally nothing happens, the scalar is never dereferenced. Transiently the processor mispredicts and loads from whatever address we picked. The loaded value then indexes a BPF array map, which is where the covert channel comes in. Array maps can be mapped into userspace with BPF_F_MMAPABLE, so Flush+Reload recovers the index.

BPF path used for the Spectre-PHT exploit.

This gives an attacker an arbitrary speculative read into the kernel. To read something useful, previous exploits swept the direct physical map of the kernel until they arrived at the information they wanted to leak. This is a bad choice for the CPUs we tested, because while the leakage is very precise it is also kind of slow. Instead we use the fact that Linux keeps recently read files in the page cache. We can get the inode number of the target file through the public stat interface. Then we leak a filesystem pointer, which we recover by walking pointers from init_task. After we have both the inode number and the filesystem pointer we can compute the page-cache hash, find the cached page, and read the target file contents directly.

Translating a file name to the location of its contents with our exploit.

3. Which Instruction Stops Speculation?

The missing fence raises an obvious question. Which instruction should the JIT emit instead?

RISC-V does not really have an answer. x86 has lfence and ARM has CSDB, but the RISC-V fence only orders memory operations. It says nothing about speculation. Linux assumes such an instruction exists anyway, so barrier_nospec() just compiles to a no-op.

So we tested 12 candidate instructions on both cores, and went back to the vendors with what we found.

fence.i stops speculation on both cores, in user code and in kernel code. CSR reads are the cheaper option, and T-Head confirmed that they terminate speculation on the C910/C920. On the P550 we measured the same for rdtime, though that one is our own result rather than a vendor statement. SiFive proposed a third option for kernel code on the P550, a CSR write to stvec that leaves the register unchanged. We verified it on the board, and it stops speculation both after faults and after branch mispredictions.

Here are all three as inline assembly you can drop into your own code.

// Both cores, user and kernel. Safe default, flushes the icache.
static inline void spec_barrier_fencei(void)
{
 asm volatile("fence.i" ::: "memory");
}

// Lower overhead. Unprivileged, so it also works in user code.
static inline void spec_barrier_rdtime(void)
{
 asm volatile("rdtime t0" ::: "t0", "memory");
}

// SiFive P550, kernel only. stvec is a supervisor CSR.
static inline void spec_barrier_p550_smode(void)
{
 asm volatile("li t0, 0\n\t"
 "csrrs x0, stvec, t0" ::: "t0", "memory");
}

Note that fence.i is the expensive one, at 46.6x geometric mean on SPEC CPU 2017 against 2.69x for rdtime.

None of these are architecturally guaranteed, so they may not hold on future cores. The RISC-V Speculation Barrier Task Group is working on a real one, the draft Zisb extension. The paper has the full table and the methodology behind it.

4. Finding Missing Mitigations by Diffing Architectures

The mitigation story was the part that surprised me most. For x86 and ARM, many Spectre fixes have been added piecemeal since 2018. For RISC-V, many equivalent paths simply had not received the same treatment. The annoying part is that the matching code often does not have the same names or live in the same files. So we used the existing fixes as search queries. We first collected 44 mitigation sites from kernel hardening work on other architectures. Then we extracted 2187 RISC-V kernel functions and embedded the source code with UniXcoder. The embedding search ranked RISC-V functions by semantic similarity to the already-hardened x86 and ARM locations. We then checked the high-ranking matches manually to see whether the RISC-V path had an equivalent barrier, mask, or dispatch hardening. Among the 15 sites with clear RISC-V equivalents, none had the corresponding mitigation in the unmodified kernel. We found missing hardening in the BPF JIT, syscall dispatch, user copy, futex, and KVM paths.

Mapping existing x86 mitigations to RISC-V code.

We contributed Linux kernel patches for the issues we found. Some are already merged, while others are still part of ongoing hardening work.

5. Branchless Dispatch Instead of Retpolines

The compiler side has a similar porting problem. Retpolines sound like the obvious answer for Spectre-BTB, but on RISC-V they are awkward. They rely on the return stack buffer not falling back to BTB predictions when it underflows. RISC-V also keeps the return address in ra, so the only known design is skip-prologue, which needs a strict two-phase prologue. The existing LLVM retpoline prototype fails on SPEC CPU 2017 because prologue generation does not consistently produce that layout. So we also tried a different design: remove the indirect branch from dispatch entirely.

The prototype is a branchless JIT dispatch mechanism. When the interpreter resolves the next handler, it asks a tiny JIT stub to encode a direct jal to that handler. The stub computes the PC-relative offset, packs it into the immediate fields of the jal instruction, writes the instruction into a small executable buffer, and executes fence.i. The buffer then contains a direct jump to the handler and a direct jump back to the caller. The predictor now sees direct jumps instead of an attacker-controlled indirect target. The JIT compiler writes the jump, and execution then transfers into the JIT buffer.

Preventing indirect jumps by instead JIT compiling a direct jump.

We evaluated this idea in a uBPF interpreter prototype. The overhead depends on how dispatch-heavy the program is, ranging from 1.2x to 22x in our experiments.

6. Artifact and Reproducibility

The artifact is on GitHub. We tried to make it useful both for reproducing the paper’s results and for building tests for new RISC-V CPUs.

Paper: riscv_spectre_sec26.pdf
Artifact: https://github.com/s8lvg/riscv-spectre-artifact

VeriFence changed BPF from rejecting these Spectre-PHT gadget patterns to accepting them with inserted BPF_NOSPEC barriers. ↩︎

Spectre | Lukas Gerlach