Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
- Reply: Poul-Henning Kamp: "Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative"
- In reply to: Poul-Henning Kamp: "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 13:09:15 UTC
On Tue, 10 Sep 2024 12:24:07 +0000 "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote: > -------- > Vadim Goncharov writes: > > > It's easy for your Lua code (or whatever) code to hang kernel by > > infinite loop. Or crash it by access on arbitrary pointer. > > 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". > > 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. > > > > Don't know what that is, quick googling […] > > 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. <<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-Architecture-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. -- WBR, @nuclight