Overview

On the T-Head Xuantie C910, a BPF type-confusion gadget can turn PHT misprediction into a transient kernel read when the RISC-V BPF JIT emits no instruction for BPF_NOSPEC. In the study’s vendor-supported Linux 6.6.119-th1520 experiment, verification was disabled to admit the proof of concept: a 1,050-byte /etc/shadow file was extracted in 3.2 seconds on average, with 100% byte accuracy in 77 of 100 attempts and a median leakage rate of 338 bytes per second. The result remains dependent on configuration, target data, and channel.

Learning outcomes

On the C910, the RISC-V BPF JIT’s no-op for BPF_NOSPEC removes the barrier expected by the verifier.
The study extracted 1,050 bytes under stated conditions, but its result is not a claim about every C910 deployment.
A security annotation becomes a boundary only when verifier policy, JIT lowering, and processor behavior retain the same meaning.

Keywords

RISC-VBPFC910BPF_NOSPECJITkernel

From a Branch Misprediction to Kernel Data

This chapter follows the BPF-assisted Spectre-PHT case on a T-Head Xuantie C910 to answer a concrete systems question: where does a security guarantee live when an untrusted program passes through a verifier, a just-in-time compiler, and a speculative processor? The case matters because it turns a predictor measurement into a kernel-confidentiality problem. It also gives a practical test for security claims: an annotation or policy is protection only if the generated instructions and the processor’s behavior preserve its meaning.

The security intent begins before the CPU

BPF programs can be loaded into the Linux kernel and executed as native code after just-in-time compilation. That arrangement has an obvious security advantage: the kernel does not have to trust every program simply because it is syntactically valid. A verifier can inspect control flow and data use, reject dangerous patterns, or mark paths that require special protection. But the verifier is not the final executor. Its decision must cross an interface into the JIT compiler, and the JIT must express that decision in instructions whose security behavior is real on the target processor.

The study’s BPF case centers on a type-confusion pattern. A program can carry either a valid pointer or a scalar value in a register. On the architectural path, a branch distinguishes those cases, and the scalar path is never supposed to be dereferenced. If the processor has learned to expect the pointer path, however, it may transiently follow that prediction when the scalar path is presented. The wrong-path load can then use an attacker-controlled value before the branch resolves. The architectural rules still reject the invalid dereference; the transient operation is the problem.

Linux has a concept for this boundary: BPF_NOSPEC. The verifier can insert such a marker at a potentially dangerous point. On other architectures, the JIT lowers the marker into an architecture-specific speculation barrier. The paper reports that the x86 BPF backend emits lfence, while ARM64 emits a speculation barrier when available and otherwise uses a stronger sequence involving instruction and data synchronization. The marker therefore has a clear intended lifecycle: policy identifies a risk, code generation emits a barrier, and the processor gives that barrier the required effect.

On RISC-V, the lifecycle breaks at code generation. The study reports that the RISC-V BPF JIT emits no instruction for BPF_NOSPEC. From the verifier’s perspective, a protection was inserted. From the native code’s perspective, there is no corresponding operation to constrain speculation. The mismatch is more serious than an omitted optimization. It means that the same security-aware kernel policy has different meanings depending on the architecture to which BPF is compiled.

Published by DeepMox

FAQ

Why did BPF_NOSPEC fail to protect the RISC-V BPF path?

It failed in the tested RISC-V path because the BPF JIT emitted no native instruction for BPF_NOSPEC, so the verifier’s marker did not constrain speculation. The source-level policy therefore had no matching machine-level effect.

What were the C910 BPF disclosure conditions?

The demonstrated experiment used vendor-supported Linux 6.6.119-th1520 with verification disabled to admit the proof of concept on a C910. The path also depended on predictor behavior, unprivileged BPF, a reachable gadget, target-data state, and an observation channel.

What did the C910 experiment actually recover?

It recovered a 1,050-byte /etc/shadow file in 3.2 seconds on average, with 100% byte accuracy in 77 of 100 attempts; median leakage was 338 bytes per second. These figures describe the tested conditions, not every deployment.

Previous11 minRISC-V Spectre on Commercial Silicon

Next11 minRISC-V’s Missing Speculation Contract

RISC-V BPF Spectre on T-Head Xuantie C910

From a Branch Misprediction to Kernel Data

The security intent begins before the CPU

FAQ