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

On 10 Sep 2024, at 14:44, Vadim Goncharov <vadimnuclight@gmail.com> 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