Re: [PATCH] riscv, bpf: add a speculation barrier for BPF_NOSPEC

[Luis Gerhorst <luis.gerhorst@fau.de>]

Lukas Gerlach <lukas.gerlach@cispa.de> writes:

> I have not benchmarked fence.i in the eBPF context specifically, but
> from my other work on Spectre mitigations on RISC-V I can confirm that
> fence.i flushes the instruction cache on all cores I have tested, both
> in-order and out-of-order, so there is a performance impact.
>
> I agree that making this conditional similar to ARM64's proton-pack.c
> is the right approach. Getting this infrastructure in place is a good
> idea regardless, as the RISC-V hardware landscape is very diverse, and
> we will likely need conditional mitigation support for other Spectre
> defenses as well.

Thanks for the patch, I believe this approach makes sense.

For eBPF, you can make them conditional by implementing
bpf_jit_bypass_spec_v1/v4() similarly to how powerpc does it [1]. They
default to false for archs that do not implement them. Setting them will
not only avoid the performance bumb, but also speed up verification and
improve expressiveness (i.e., fewer programs are rejected for some edge
cases).

I am not familiar with RISC-V, but could the be any problem from fence.i
being an extension [2]? Or do all RISC-V CPUs supported by the kernel
implement this?

[1] https://lwn.net/ml/all/20250603211318.337474-1-luis.gerhorst@fau.de/
[2] https://docs.riscv.org/reference/isa/unpriv/zifencei.html

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv