That's how (why) BSD is dying (Was: BPF64)

On Tue, 10 Sep 2024 15:05:21 -0800
Rob Wing <rob.fx907@gmail.com> wrote:

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

Lua is not suitable for the discussed problem domains, don't listen to
those who did not read material and did not understand short
descriptions.

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

What's the point to waste resources on writing thing that is known to
be not accepted to base system from the very beginning? FreeBSD already
had precedent when a *ready* code framework was rejected be some FreeBSD
users' enemy, leaving FreeBSD users to suck with absolutely *no*
alternative (yep, sensors) - as ridiculous as if it was to say "current
BSD firewalls are inferior to Linux so we'll better sit without that
bad code (and firewall) AT ALL". Yes, the situation in networking for
us was for many years - and still is - exactly so.

This is exactly the way how to loose market competition and die - just
don't try to innovate and do something better than competitor; then you
find yourself porting compatibility layers after decades of rot, like
Netlink or Linuxulator ABI, in a try to at least hobble with a cane
instead of lying in a coma.

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

So do you have to say something constructive on the real subject? Or
even bikesheds are in short supply now?

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



-- 
WBR, @nuclight