Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
- Reply: Alexander Nasonov : "Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative"
- In reply to: Vadim Goncharov : "Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 10 Sep 2024 14:32:56 UTC
-------- Vadim Goncharov writes: > On Tue, 10 Sep 2024 12:24:07 +0000 > "Poul-Henning Kamp" <phk@phk.freebsd.dk> 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 | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.