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

On Tue, 10 Sep 2024 12:24:07 +0000
"Poul-Henning Kamp" <[email protected]> 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