Overview
This series asks whether the RISC-V ISA is enough to establish speculative-execution security. Evidence from the SiFive P550 and T-Head Xuantie C910/C920 shows that commercial out-of-order cores expose different Spectre surfaces, while firmware, kernels, JITs, and compilers can preserve or lose a mitigation’s meaning, and tooling can miss architecture-specific gaps. It moves from mechanism and measurements to a BPF kernel-data disclosure case, conditional defenses, and an explicit contract. Claims remain processor-, configuration-, and test-specific.
Learning outcomes
- The RISC-V ISA does not by itself guarantee how predictors or transient effects behave.
- The tested P550 and C910/C920 expose broad, configuration-dependent Spectre behavior.
- A verifier marker or kernel macro protects only when the backend emits effective native behavior.
- Current defenses are conditional stopgaps; durable portability needs an explicit, validated speculation contract.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
Does the RISC-V ISA guarantee Spectre resistance?
No; the base RISC-V ISA does not guarantee Spectre resistance or provide a dedicated speculation barrier. Security depends on core behavior, firmware, software lowering, and validation.
What did commercial RISC-V testing actually show?
The study found 12 of 13 tested Spectre variants succeeded on both the SiFive P550 and T-Head Xuantie C910/C920, with precision above 97%, while recall varied by predictor, address relationship, and configuration. No leakage was observed on the tested in-order U74, C906, and C908, which is not an ISA-level guarantee.
How can a RISC-V software mitigation fail?
It can fail when a verifier marker or generic barrier lowers to no instruction, or to an operation without the required architectural meaning. The BPF JIT and barrier_nospec examples show how source intent can disappear before execution.
What makes a RISC-V Spectre defense reliable?
A defense is most reliable when its architectural meaning, processor and firmware scope, generated code, and target-hardware validation are explicit. Without a ratified barrier, masking, SLH, retpolines, branchless dispatch, and probes remain conditional measures.