Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative

[David Chisnall <theraven%FreeBSD.org@localhost>]

On 10 Sep 2024, at 14:44, Vadim Goncharov <vadimnuclight%gmail.com@localhost> wrote:

I am not an experience assembler user and don't understand how Spectre
works - that's why I've written RFC letter even before spec finished - but
isn't that (Spectre) an x86-specific thing? BPF64 has more registers
and primarily target RISC architectures if we're speaking of JIT.

No, speculative execution vulnerabilities are present in any CPUs that do speculative execution that does not have explicit mitigations against them (i.e. all that have shipped now).  Cache side channels are present in any system with caches and do not have explicit mitigations (i.e. all that have shipped so far).

Mitigations around these things are an active research area, but so far everything that’s been proposed has a performance hit and several of them were broken before anyone even implemented them outside a simulator.

And BPF64 is meant as backwards-compatible extension of existing BPF,
that is, it has bytecode interpreter (for(;;) switch/case) as primary
form and JIT only then - thus e.g. JIT can be disabled for non-root
users in case of doubt. eBPF can't do this - it always exists in native
machine code form at execution, bytecode is only for verifier stage.

This has absolutely no impact on cache side channels.  The JIT makes some attacks harder but prime-and-probe attacks are still possible.

BPF can be loaded only by root, who can also load kernel modules and map /dev/[k]mem, and FreeBSD does not protect the root <-> kernel boundary.

Please read some of the (many) attacks on eBPF to better understand the security landscape here.  It’s a *very* hard problem to solve.

David