The Missing Contract Across the Stack

The RISC-V Spectre problem now has a misleadingly simple symptom: a protection appears in the source, but the processor does not receive a protection with the same meaning. This chapter diagnoses the deeper failure across Linux, compilers and JITs, hardware, and firmware. The aim is to separate four things that are easy to conflate—an absent architectural guarantee, an incomplete port, a tooling blind spot, and a configuration difference—so that later defenses can be judged by the layer they actually repair.

The first failure is an architectural omission

A Spectre defense needs a way to constrain unsafe speculative work. On x86, the security role of lfence has been established for this purpose; ARM provides mechanisms such as CSDB and ISB. The USENIX study finds that the base RISC-V ISA has no dedicated speculation-barrier instruction. That is not just a missing convenience for kernel developers. It means that software has no portable instruction whose specified purpose is to say, “do not continue speculative execution past this boundary.”

RISC-V does provide fence, but its architectural job is to order memory operations. Ordering memory is not the same as stopping the processor from issuing instructions on a wrong path. A processor may implement a memory fence in a way that also happens to delay speculation, but software cannot infer that extra effect from the instruction’s memory-ordering semantics. The proposed fence.t extension would address the gap more directly, according to the paper, but it was not ratified and was unavailable on the commercial processors evaluated.

This omission explains why the BPF failure cannot be repaired by a purely textual substitution. A maintainer can replace a no-op with an instruction, yet still not know whether that instruction has the required security effect on every implementation. The study profiles candidate instructions rather than assuming their behavior. It tests memory-fence variants, the instruction-cache fence, counter reads, and other instructions that might serialize the pipeline. The results differ by core: on the C910, most fence variants and CSR reads appear to stop speculation in the tested setup, while fence.tso and lr.d do not; on the P550, only fence.i and rdtime reliably stop speculation after the tested load/store faults.

Those observations are useful engineering evidence, but they are not a specification. The experiment uses exceptions as an overapproximation: after an exception, the researchers observe whether transient accesses occur beyond the candidate instruction. An instruction that suppresses all memory effects without stopping speculative issue could look effective in a cache test while remaining observable through a non-memory channel, such as resource contention. The method can identify promising stopgaps; it cannot turn an implementation accident into a portable guarantee.

That distinction is the root diagnosis. If the ISA supplied a dedicated, architecturally defined barrier, compilers and kernels could target a known contract and processors could be tested against it. Without one, every downstream layer has to guess, probe, or rely on vendor-specific knowledge. A patch may be correct for one processor and still lack a defensible meaning for another.

The second failure is a translation and visibility problem

The architectural omission would already be difficult. It becomes more dangerous because software security interfaces were built around assumptions inherited from architectures with more mature Spectre support.