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

["Poul-Henning Kamp" <phk%phk.freebsd.dk@localhost>]

--------
Vadim Goncharov writes:
> On Tue, 10 Sep 2024 12:24:07 +0000
> "Poul-Henning Kamp" <phk%phk.freebsd.dk@localhost> wrote:
>
> > Lua has pointers now ?
>
> It's implementation has.

As does (e)BPF's implementation.

> > You're yelling at the guy who implemented a (very fast!) firewall
> > where the rules were compiled to C code in a KLD.
>
> That's exactly the way which must be avoided. See 5.2 of
> https://www.usenix.org/legacy/events/bsdcon02/full_papers/lidl/lidl.pdf

I didn't agree with them then, and I dont agree with them now :-)

In my implementation, the ipfw(8) worked *precisely* the same as
it always did, just a little slower because it had to run the
C-compiler.

Later I used the same trick in Varnish, where the "VCL" configuration
language is compiled into a shared library, a major performance gain.

> You're either trolling or completely misunderstand the problem domain. 
> [wiki quote]
> This has nothing to do with BPF at all. Go and read original papers on
> kernel filters and why they're *such* restricted, e.g. Van Jacobson's
> paper on BPF/tcpdump, aforementitioned paper on BSD/OS's IPFW (esp.
> section 5.7 on loops), etc.

Yes, I read those papers when they were fresh, and I still think I
know more about this problem domain than you will ever have to
learn.

I will admit that I have not run channel programs on a 709 myself,
I only got into that game on a 4381.

I also wrote my own prototype eBPF around 1996-97, in an attempt
to deal with some obscure protocols, but I gave up on it, precisely
because BPF was a "toy" language so it couldn't do what I needed.

There are two fundamental questions:

A) How powerful do you want the downloaded bytecode to be ?

B) What syntax to you express it in ?

There are basically two possible answers to A.

Either the downloaded code is "real", which means it can include
loops, function calls etc. or it is a "toy" which relies on
Brinch-Hansen's "all arrows point to the right" argument to prove
that it will always terminate.

Obviously there is a lot of stuff you cannot do with a "toy",
but it is a valid trade-off.

VJ had no trouble making BPF a "toy":  He lost no functionality,
and it made it easier/possible to convince people that this would
not cause the same problems as IBM channel programs did.

I made VCL a "toy", also because no functionality was lost, and
it eliminated a very obvious way for webmasters, not the worlds best
programmers to begin with, to shoot their own feet.

Personally I think it should be a "securelevel" like setting if
FreeBSD's channel programs should be allowed to loop:  We supply
code, not policy.

But that question is /entirely/ separate from the second question.

The answer to that is that you can write them in /any/ programming
language you want, as long as the interpreter for the resulting
(byte-)code an spot attempts to jump backwards, and refuse to
do so, if so configured.

And that is why I say: If we're going to do this, let us do
it with Lua:  It's already in our tree and it will do the
job nicely.

After all, we dont want to make another mess like ACPI, do we ?

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk%FreeBSD.ORG@localhost         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.