From nobody Tue Sep 10 14:32:56 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X35lZ4fQvz5Vvq9; Tue, 10 Sep 2024 14:32:58 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X35lZ24jdz4Vq2; Tue, 10 Sep 2024 14:32:58 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 9C8EE892DA; Tue, 10 Sep 2024 14:32:56 +0000 (UTC) Received: (from phk@localhost) by critter.freebsd.dk (8.18.1/8.16.1/Submit) id 48AEWu1q094702; Tue, 10 Sep 2024 14:32:56 GMT (envelope-from phk) Message-Id: <202409101432.48AEWu1q094702@critter.freebsd.dk> To: Vadim Goncharov cc: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tech-net@NetBSD.org, Alexander Nasonov Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative In-reply-to: <20240910160915.55ff579b@nuclight.lan> From: "Poul-Henning Kamp" References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <202409101224.48ACO7oj094058@critter.freebsd.dk> <20240910160915.55ff579b@nuclight.lan> List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94700.1725978776.1@critter.freebsd.dk> Date: Tue, 10 Sep 2024 14:32:56 +0000 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Queue-Id: 4X35lZ24jdz4Vq2 -------- Vadim Goncharov writes: > On Tue, 10 Sep 2024 12:24:07 +0000 > "Poul-Henning Kamp" 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.