An Explicit Speculation Contract for RISC-V

The title’s answer can now be stated precisely. An open ISA does not eliminate Spectre because Spectre is produced by the interaction between programmer-visible instructions and microarchitectural behavior that the base ISA does not fully specify. The subject is the security relationship among RISC-V, commercial out-of-order processors, and the software stack that runs on them. The judgment that matters is therefore not whether “RISC-V” is safe in the abstract, but whether a particular deployment can state, discover, implement, and validate the speculation guarantees on which its isolation depends.

The same ISA can describe different security surfaces

RISC-V International presents RISC-V as an open, modular, customizable, royalty-free instruction-set architecture. That openness is a design and ecosystem property: independent organizations can build different processors and extend them within a shared framework. The USENIX study shows why the same property cannot be used as a shortcut for security equivalence. An ISA tells software how committed operations behave; it does not automatically dictate the number of predictor entries, the way a branch-target buffer is indexed, what happens when a return predictor underflows, or which internal effects remain observable after a wrong-path computation is discarded.

That separation explains the importance of testing commercial silicon. The study examines the SiFive P550 and T-Head Xuantie C910/C920, described as the commercially available out-of-order RISC-V processors available to the authors at the time of writing. Across 13 configurations and four major Spectre families, the study’s summary reports that 12 of 13 variants succeed on both processor designs, with precision above 97% for all variants. The result establishes that high-performance commercial RISC-V implementations can expose the same broad class of speculative side-channel behavior that made Spectre a persistent problem on other architectures.

It does not establish that every RISC-V processor behaves the same way. The recall figures vary sharply by processor and by the relationship between attacker and victim. PHT recall on the C910/C920 is high for same-address cases and lower for cross-address cases; the P550 shows a different pattern, including much lower recall in some cross-address configurations. BTB recall is high on the C910/C920 when enabled and lower on the P550. RSB attacks succeed in most tested relationships but fail in the cross-address, in-place case. STL succeeds in its tested in-process configuration. These differences are not noise around one universal security state. They are evidence that the implementation and the sharing boundary are part of the security surface.

The firmware setting for the BTB makes the point especially clearly. The C910 and P550 ship with the BTB disabled, while the C920 enables it by default; the researchers enable it to characterize the full attack surface. The C910 and C920 are treated as one core microarchitecture for the relevant analysis, yet their system configurations still differ. The evaluated designs also implement a user/kernel BTB split, which prevents the tested cross-privilege poisoning path while leaving same-privilege attacks possible. Neither design falls back from an exhausted RSB to the BTB, a property that supports retpolines on those cores but is not promised by the base ISA.

A negative result has the same conditional character. The authors report no leakage on the particular in-order U74, C906, and C908 processors they tested. That observation may indicate a narrower speculative window, a different predictor design, or the absence of a usable path through the tested channel. It does not prove that all in-order RISC-V cores are immune, any more than the commercial result proves that all RISC-V cores are vulnerable. The right unit of judgment is the tested implementation under stated conditions.

One causal chain connects the hardware and software failures

The evidence becomes more coherent when treated as one chain rather than as separate findings. A predictor lets a commercial out-of-order core begin work before a condition is resolved. A wrong-path operation can leave a cache or other microarchitectural trace after architectural rollback. A software gadget supplies a sensitive operation. A compiler, JIT, or kernel interface is supposed to prevent that operation from becoming observable. If the interface is lowered incorrectly, the processor’s ordinary performance machinery becomes a confidentiality channel.

The BPF case makes that chain concrete. Linux’s BPF verifier can identify a dangerous pattern and insert BPF_NOSPEC. On x86, the paper reports that the JIT lowers the marker to lfence; on ARM64, it emits a suitable speculation barrier when available or falls back to synchronization instructions. On RISC-V, the BPF JIT emits no instruction for the marker. The verifier’s policy is therefore present in the source-level logic but absent from the native instruction stream.