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

On Tue, 10 Sep 2024 06:38:50 +0000
"Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:

> --------
> Vadim Goncharov writes:
> 
> > I've put a sketch of design to https://github.com/nuclight/bpf64
> > with files:  
> 
> Counter proposal:
> 
> 1. Define the Lua execution environment in the kernel.
> 
> 2. Add syscall to submit a precompiled Lua program (as bytecode)

Anyone who thinks "any generic bytecode" misses the main point, see
below.

> 3. Add syscall to execute submitted Lua program
> 
> And yes:  I'm being 100% serious.

Well, preparing spec/letter in a rush I probably forgot the main reason
for BPF (and successors) to exist thinking it's obviuos: safety.

Let's restate: *BPF* allows UNTRUSTED user code to be executed SAFELY
in kernel.

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.

And that's why DTrace also has it's own VM and bytecode in kernel
(see https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-924.pdf Chapter 7)

Your "counter proposal" was essentially available for all these decades
in form "oh, just write KLD in C instead of that limited tcpdump".

> If we are going to reinvent "Channel Programs" 67 years after IBM
> came up with them for their 709 vacuum tube computer, at the very
> least we should use a sensible language syntax.

Don't know what that is, quick googling shows something modern on AMQP.

But Lua at least doesn't have *sensible* syntax, Perl or Tcl much better.
And I'm surprised why Fort, being available in loader, wasn't ported
for all these years.

-- 
WBR, @nuclight