When RISC-V Reaches Commercial Silicon
The question here is narrower than whether RISC-V is “secure”: what did measurements on the SiFive P550 and T-Head Xuantie C910/C920 actually demonstrate about Spectre, and how much of that result belongs to those implementations rather than to the ISA? Answering it lets us read the study as engineering evidence—complete with configuration effects, differing reliability, and negative results—rather than as a binary label attached to RISC-V.
From research prototypes to named silicon
Earlier RISC-V Spectre research had concentrated on academic or research-grade processors. Those designs are valuable because researchers can modify their hardware, test proposed defenses, and inspect internal behavior. But a result on a research core leaves an important deployment question open: does the same class of speculative behavior exist in commercial hardware that runs production software?
The USENIX study addresses that gap by examining the SiFive P550 and the T-Head Xuantie C910/C920. The authors describe these as the commercially available out-of-order RISC-V processors available to them at the time of writing. This wording matters. It identifies the scope of the evidence instead of pretending that a finite set of boards represents every processor that implements RISC-V. The C920 is analyzed together with the C910 for the relevant security behavior because its change from the C910 is the vector extension, while the core microarchitecture is treated as identical.
The study uses a unified framework covering 13 configurations across the four major families introduced earlier: PHT, BTB, RSB, and STL. It also varies how the attacker and victim relate to the predictor: they may use the same or different addresses, and the training may occur at the instruction eventually exploited or at a different colliding instruction. This design matters because a predictor is a shared state machine, not a simple property of a branch opcode. Measuring only the easiest same-instruction case would leave unanswered whether state crosses process or address boundaries.
The measurement unit is a byte-leakage attempt rather than a vague observation that “the branch mispredicted.” Each iteration encodes one of 256 possible byte values into the cache state, and the experiment probes the possible outcomes afterward. Recall then captures how often the intended leakage is recovered under a configuration, while precision records how trustworthy the identified result is. Reporting both is important: a path that succeeds less often may still be useful if its guesses are accurate and the attacker can repeat it, while a high apparent success rate is less meaningful if the inferred values are noisy.
For comparison, the authors test particular in-order processors—the SiFive U74 and Xuantie C906 and C908—and report no leakage on those systems. That is a useful boundary condition, but it is not a conclusion about all in-order RISC-V cores. Nor does it negate the commercial out-of-order result. The study is comparing concrete implementations and configurations, not assigning an architectural security grade to the RISC-V name.
The same vulnerability is not one same result
The headline finding is broad: the paper’s summary reports that 12 of the 13 tested Spectre variants succeed on both commercial processor designs, with precision above 97% for all variants. The breadth is the important result, but the individual recall figures show why “succeeds” should not be read as “works identically.” Recall varies with processor, predictor family, address relationship, and branch placement.
The PHT results make that visible. On the C910/C920, the reported recall is 93.3% for the same-address, in-place configuration and 87.1% for same-address, out-of-place training. Cross-address configurations are lower—75.0% in-place and 56.9% out-of-place. On the P550, same-address in-place recall is reported at 99.8%, while the other configurations fall as low as 2% for cross-address, out-of-place training. The precision remains high, so a lower recall means the attack needs more attempts; it does not mean that the processor has no PHT attack surface.
BTB behavior differs again. With the predictor enabled, the C910/C920 shows recall from 92.2% to 99.2% across the four tested relationships. The P550 ranges from 4.0% to 30.2%. The gap is substantial, but it should not be translated into “C910 is vulnerable and P550 is safe.” A repeatable attack with lower recall can still matter, especially when the attacker can retry. The relevant engineering question is how much effort and time the configuration imposes, not whether a single experiment succeeds every time.
The RSB results are high for most tested relationships: same-address and out-of-place variants exceed 99% on both designs. The cross-address, in-place variant fails on both, with zero percent recall in the reported tests. The paper attributes that boundary to the kernel transition flushing the RSB and to privilege-mode tagging preventing cross-domain speculation. STL is also reported above 99% on both processors in its tested in-process configuration. These results show both breadth and selectivity: different structures expose different paths, and a defense or isolation measure aimed at one path does not settle the others.
Recall and precision are not the only measurements that matter. The study also validates its cache leakage primitives without speculation and uses the cache as the observation channel for the attack experiments. That gives the results a defined measurement basis. It does not prove that every possible side channel has been tested, nor that another processor with a different cache or predictor will produce the same signal. Evidence becomes more useful when the channel and test conditions are named.
The experimental design also separates two questions that are often conflated. The first is whether a predictor can be influenced in the required way. The second is whether the resulting transient activity can transmit a value reliably enough to be recovered. A processor can make training difficult without eliminating the underlying behavior, or can permit a wrong-path execution whose residue is too weak for the tested channel. That is why the study’s tables should be read as maps of practical attack conditions, not as a complete inventory of every speculative event inside the chip.
The relationship in the diagram is the study’s central measurement lesson. Both processors implement the same broad ISA, but their predictor structures and observed outcomes are not interchangeable. The evidence belongs to the concrete path from implementation to measurement.
Configuration is part of vulnerability
The most instructive difference is the branch-target buffer’s default state. The C910 and P550 ship with the BTB disabled, while the C920 enables it by default. The researchers enable the BTB for their experiments so that they can characterize the full attack surface. That choice is methodologically sensible, but it also exposes a deployment fact: two systems can run RISC-V software while presenting different transient behavior because firmware configures the predictor differently.
A disabled BTB should be interpreted narrowly. It reduces or removes the tested BTB path under that configuration; it does not turn off all speculative execution, erase the PHT, RSB, or store-to-load mechanisms, or supply a general architectural statement about speculation. Conversely, enabling the BTB does not create a new instruction-set feature. It exposes more of the implementation’s existing behavior to software and to an attacker who can meet the other conditions. Configuration changes the practical surface, but it does not replace a contract that says what software may rely on.
Disabling a predictor can reduce the surface of one attack family, but it is not equivalent to proving that the processor is resistant to Spectre. Other predictors and dependency mechanisms remain. A configuration change can also be reversed by a firmware update, a board variant, or a vendor default. Security-relevant defaults must therefore be recorded and controlled, not treated as incidental setup details.
Both evaluated designs implement a user/kernel split in the BTB. The split prevents the tested cross-privilege BTB poisoning path, but it does not make all prediction state private. Same-privilege attacks remain possible, including cross-process attacks in userspace and intra-kernel paths reached through BPF. This is a useful example of why the phrase “the kernel is isolated” needs a qualifier. Isolation of one predictor structure across two privilege levels is a narrower property than isolation of every transient resource.
The RSB supplies another implementation-specific result. The C910/C920 has a measured 12-entry RSB and the P550 a 16-entry RSB. More important than the exact sizes is what happens at exhaustion. Neither tested design falls back to the BTB when the RSB underflows, and neither exhibits the straight-line speculation behavior tested by the authors. That makes retpolines potentially effective on these implementations because an incorrectly predicted return does not escape into a poisoned BTB target. But the conclusion is conditional. A different RISC-V core could choose different underflow behavior while remaining compatible with the base ISA.
This is a good example of the difference between a defense pattern and a defense guarantee. A retpoline changes an indirect transfer into a sequence that relies on return prediction being contained. Its success depends on the processor’s RSB behavior and on the compiler producing the expected calling and prologue structure. The measured absence of BTB fallback supports the pattern for the evaluated cores; it does not let a compiler assume that every RISC-V return mechanism behaves the same way. What looks like a source-level transformation is really a promise about hidden hardware state.
The lack of simultaneous multithreading on the tested processors also affects the results. It removes an easy way to train predictor state from a sibling thread at the same time as the victim runs. Cross-address attacks can still work, but context switches may disturb the state and reduce recall. Again, a lower success rate is not the same as absence of a vulnerability; it is evidence about the resources and scheduling conditions available to the attacker.
What negative results do—and do not—mean
A good security measurement records its non-results as carefully as its successful attacks. The in-order U74, C906, and C908 systems showed no leakage in the authors’ tests. That may reflect limited speculation, different pipeline behavior, an unavailable gadget, or the tested channel and conditions. The paper does not turn those observations into an architectural guarantee, and neither should a reader.
The same caution applies to the 12-of-13 summary. It is strong evidence that the two named commercial out-of-order designs expose a broad Spectre surface. It is not a census of all current RISC-V silicon, because the processor set is bounded by what the authors could access and by the time of the study. Nor does it say that every variant works across every address-space or privilege relationship. The table is informative precisely because it preserves those distinctions.
This is not a weakness to be hidden by a broader headline. External validity in microarchitectural security is conditional by nature. A processor generation, firmware image, privilege mode, scheduler, cache design, or compiler output can change whether a gadget is reachable or a signal is measurable. The right response to that conditionality is better disclosure of the tested state and repeatable validation on the target platform—not the assumption that an ISA-level family name fills in missing details.
This is also why the C910/C920 pairing should be read carefully. Treating them as one core microarchitecture is reasonable for the relevant analysis, yet their BTB defaults differ. The implementation may be shared while the system configuration is not. A security report that omits firmware state can therefore make two different machines look more equivalent than they are.
From a processor result to a deployment question
The practical conclusion is not that every RISC-V deployment is already compromised. It is that “RISC-V” is too coarse a security descriptor for a high-performance system. A deployer needs to know the concrete core, active predictor features, privilege partitioning, software path, and measurement conditions behind any mitigation claim. A maintainer needs to know whether a defense relies on an implementation behavior that the ISA does not promise.
The commercial results also change the status of software hardening. Before hardware evidence existed, a missing RISC-V mitigation could be dismissed as a precaution for a research platform. Once named out-of-order processors demonstrate the relevant behavior, an unimplemented barrier or an unprotected kernel gadget becomes a live compatibility and security problem. The next step is to follow one such path through Linux and BPF, where the processor’s transient behavior meets a software stack that believes it has already inserted a defense.