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

On Tue, 10 Sep 2024 13:59:02 +0100
David Chisnall <theraven@FreeBSD.org> wrote:

> On 10 Sep 2024, at 12:45, Vadim Goncharov <vadimnuclight@gmail.com>
> wrote:
> > 
> > It's easy for your Lua code (or whatever) code to hang kernel by
> > infinite loop. Or crash it by access on arbitrary pointer. That's
> > why original BPF has no backward jumps and memory access, and eBPF's
> > nightmare verifier walks all code paths and check pointers.  
> 
> I’m not convinced by the second: Lua has a GC’d heap, you’d need to
> expose FFI things to it that did unsafe things, and that’s equally a
> problem for eBPF.

Not quite. For eBPF (and BPF64) there must be not just FFI but special
wrappers or even written from scratch functions keeping in mind they
work for restricted environment. Lua, of course, does not have such
thing - it will be needed to reimplement standard library.

> The first is not a problem.  The Lua interpreter has a bytecode
> limit.  You can define a bounded number of bytecodes that it will
> execute.  The problem comes from the standard library.  Things like
> string.gmatch can have high-order polynomial complexity and so it’s
> possible for a Lua program that executes a small number of bytecodes
> to create a string that takes a vast amount of time to match on.
> Again, this is also a problem for eBPF if you expose a similar
> function, the solution is to not expose functions with large
> data-dependent runtimes to untrusted script.

In BPF64 some safety belts are supposed - e.g. on CALL/RET time is
checked, and if exceeded, program is marked unsafe and disabled.

> More generally, there are a lot of problems with interpreting or
> JITing untrusted code in the kernel in *any* runtime.  Speculative
> execution makes it easy to use these as primitives to leak kernel
> secrets, either via timing of the programs themselves, using the JIT
> to generate gadgets, or by leaking data via cache priming.
> 
> Both eBPF and Lua have these problems.
> [...]
>  - Run a channel program.
> 
> In the post-Spectre world, the former remains a privileged operation.
>  Even though Linux pretends it isn’t, allowing arbitrary (even
> arbitrary constrained) code to run in the kernel’s address space is a
> problem.  Invoking such code; however, should follow the same rules
> as everything else.  A trusted entity should be able to load a pile
> of Lua / eBPF / BPF64 / whatever programs into the kernel and then
> set up permissions so that sandboxed programs (and jails) can use a
> defined subset of them.

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.

For BPF64 I've did separate stack as register window exactly to
mitigate ROP and it's gadgets.

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.

^^ that's fallback if you say "safe JIT is impossible", but may be you
have advices on how to do architecture to still do it safe? As BPF64
looks doable improvement for us in much lower resource investment than
even to *porting* eBPF to *BSD.

> The thing I would like to see for our current use of semi-trusted Lua
> in the kernel (ZFS channel programs) is a way of exposing them (under
> /dev/something) as file descriptors and modifying the ioctls that run
> them to take a file descriptor argument.  I would like to separate
> the two operations:
> 
>  - Load a channel program.

Didn't hear about, looked at the zfs-program(8) and see no reason why
these are called "channel" programs (just to please some old farts?)
and even reason for them to run in kernel, for same userland-utilities-achievable
things, seems doubtful.

-- 
WBR, @nuclight