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

[Vadim Goncharov <vadimnuclight%gmail.com@localhost>]

On Tue, 10 Sep 2024 15:58:25 +0100
David Chisnall <theraven%FreeBSD.org@localhost> wrote:

> 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.

Wait, do you want to say that problem is not in JIT, that is, that
current BPF (e.g. tcpdump) present in the kernel - are also vulnerable?
Also, let's classify vulnerabilities. Is speculative execution
vulnerability the same as cache side channels? In any case, what impact
is? E.g. attacker could leak secrets, but *where* would them leak? BPF
typically returns one 32-bit number as a verdict (often as just
boolean), is it really attack vector? That is, may be solution is just
"don't give read access to BPF-writable memory segments to untrusteds".

Next, if problem is with timing, then isn't that enough to just
restrict BPF code on having access to timers with resolution high
enough?

> 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.

Wrong. It is possible for decades to do `chmod a+r /dev/bpf*` and run
tcpdump as non-root, which will load BPF code into kernel. Is *that*
also a vulnerability, and if so, why it was never reported?

> Please read some of the (many) attacks on eBPF to better understand
> the security landscape here.  It’s a *very* hard problem to solve.
 
Finally, the most big (in effort) question: suppose we limited to
trusted root user etc. so it's of no concern. Are there now any
objections/suggestions/comments on (rest of) BPF64 ?

-- 
WBR, @nuclight