[PATCH] riscv, bpf: Emit fence.i for BPF_NOSPEC

[Paul Walmsley]

Hi Lukas, 

thanks for the patch,

On Sun, 28 Dec 2025, Lukas Gerlach wrote:

> The BPF verifier inserts BPF_NOSPEC instructions to create speculation
> barriers. However, the RISC-V BPF JIT emits nothing for this
> instruction, leaving programs vulnerable to speculative execution
> attacks.
> 
> Originally, BPF_NOSPEC was used only for Spectre v4 mitigation, programs
> containing potential Spectre v1 gadgets were rejected by the verifier.
> With the VeriFence changes, the verifier now accepts these
> programs and inserts BPF_NOSPEC barriers for Spectre v1 mitigation as
> well. On RISC-V, this means programs that were previously rejected are
> now accepted but left unprotected against both v1 and v4 attacks.
> 
> RISC-V lacks a dedicated speculation barrier instruction.
> This patch uses the fence.i instruction as a stopgap solution.
> However an alternative and safer approach would be to reject vulnerable bpf
> programs again.
> 
> Fixes: f5e81d111750 ("bpf: Introduce BPF nospec instruction for mitigating Spectre v4")
> Fixes: 5fcf896efe28 ("Merge branch 'bpf-mitigate-spectre-v1-using-barriers'")
> Signed-off-by: Lukas Gerlach <lukas.gerlach at cispa.de>

Have you been able to measure whether this change results in a performance 
regression on cores that might not need these barriers, for example, 
in-order cores with limited speculation?

Am thinking that we probably should make this conditional using code 
similar to arch/arm64/kernel/proton-pack.c - and avoiding the fence.i when 
cores that aren't likely to be susceptible are detected.

Thoughts?  


- Paul