tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative
On Tue, 10 Sep 2024 12:24:07 +0000
"Poul-Henning Kamp" <phk%phk.freebsd.dk@localhost> 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
Home |
Main Index |
Thread Index |
Old Index