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

> In general, it will require a special counter but BPFJIT compiler
> should be able to spot simple loops that process at least one byte on
> each iteration and minimise runtime overhead.

I think such a thing is a VERY bad idea.

Why?  It means that, instead of the security attack surface being that
of the pcode engine (and, if appropriate, verifier), it's not just a
compiler (which would be insane enough), but a compiler with a
relatively complex optimizer/verifier.

Perhaps this is appropriate for the sort of use case where you install
(and trust) binaries someone else built, protected by nothing stronger
than HTTPS (which, depressingly, seems to be everything but my home
machines, in my limited experience).  But the kind of network device
for which you want nontrivial (e)BPF code usually is also just the kind
of device you least want to get sloppy about exposed attack surface on.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B