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

Doesn't NetBSD have Lua in the kernel...anyone have any experience with it?

re BPF64:

looks like hand waving, proposing two unwritten languages that extends an
ISA that is still being drafted by IETF...hmm

you can make anything look good on paper but the devil is in the
details...which there are plenty of

On Tuesday, September 10, 2024, Vadim Goncharov <vadimnuclight@gmail.com>
wrote:

> On Tue, 10 Sep 2024 15:58:25 +0100
> David Chisnall <theraven@FreeBSD.org> wrote:
>
> > 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.
>
> 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
>
>