Date: Tue, 10 Sep 2024 16:09:15 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-net@FreeBSD.org, tech-net@NetBSD.org, Alexander Nasonov <alnsn@NetBSD.org> Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240910160915.55ff579b@nuclight.lan> In-Reply-To: <202409101224.48ACO7oj094058@critter.freebsd.dk> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <202409101224.48ACO7oj094058@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Sep 2024 12:24:07 +0000 "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote: > -------- > Vadim Goncharov writes: >=20 > > It's easy for your Lua code (or whatever) code to hang kernel by > > infinite loop. Or crash it by access on arbitrary pointer. =20 >=20 > Lua has pointers now ? It's implementation has. Do you have mathematical verifier of such loaded bytecode proving it's C interpreter will have no side effects during it's running? > > Your "counter proposal" was essentially available for all these > > decades in form "oh, just write KLD in C instead of that limited > > tcpdump". =20 >=20 > 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 > > > 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. =20 > > > > Don't know what that is, quick googling [=E2=80=A6] =20 >=20 > Well, you probably should do some more research then, because > unawareness of history is /the/ major cause of pointlessly repeating > mistakes. You're either trolling or completely misunderstand the problem domain.=20 <<Although the 709, one of the last of the vacuum-tube computers announced by IBM, had a rather short tech- nological life, it made an important contribution to con- current CPU and 1/0 operations by the introduction of I/O channels [21]. These channels actedindividually as I/O processors with a specialized instruction repertoire. Each channel could address and accessmemory to store orre- trieve data quiteindependently of theCPUprogram. Coordinationbetween the CPUandchannelprograms wasachieved by CPU instructions for (1) conditional branching depending on whether a channel was in opera- tion, (2) delaying the CPU until completion of a channel command, followed by loading of channel control regis- ters, and (3) storing the channel control register contents in a specified memory location. >> (c) https://www.ece.ucdavis.edu/~vojin/CLASSES/EEC272/S2005/Papers/IBM-A= rchitecture-Bashe_sep81.pdf 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. --=20 WBR, @nuclight
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240910160915.55ff579b>