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

[Paul Walmsley]

Hi,

On Mon, 12 Jan 2026, Bo Gan wrote:

> Please also check out Ved's response from the Speculation Barrier TG:
> 
> https://lists.riscv.org/g/tech-speculation-barriers/message/21
> 
> I think the best way forward is to wait for the TG to clearly define
> speculation barrier instructions, and use them for future cores. 

Waiting for the speculation barriers TG to complete their work is 
unfortunately a non-starter.  It seems unlikely to do so for quite some 
time.  Even once the extension is ratified, it's likely to take years 
before these instructions enter silicon and are widely available.  
Meanwhile, there are already newer designs in silicon targeting use cases 
that will need mitigations.

> For existing HW, emit a warning and do nothing. 

Can we really assume that this use case is the same as everyone else's?  
So far the Linux approach to microarchitectural attacks is to implement 
mitigations, with the expensive ones switchable, and then to give users 
the choice as to whether to disable mitigations for their use case.  Is 
there a reason for arch/riscv to take a substantially different approach?

> I don't want to see bpf doing fence.i universally for all riscv.

I think there's already agreement here - 

  https://lore.kernel.org/linux-riscv/20260106084410.94496-1-lukas.gerlach@cispa.de/

> Neither do I like it guessing this and that specific core implementation 
> needing fence.i or not. We simply don't know how each vendor design 
> their cores. Let the vendor tell us what's the best instruction to use 
> for our existing HW.  E.g., for JH7110, it's really U74 from Sifive, so 
> we can ask them to fill-in

We should make sure that the sequence used can be determined per- 
microarchitecture.  But if there's no guidance from the vendor, then the 
community should implement something that seems to work.  This should also 
encourage vendors to engage with us to make sure that the most efficient 
workarounds or mitigations are implemented.  That hopefully should also 
encourage vendors to design hardware that don't have these known 
vulnerabilities.


- Paul