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

Mouse wrote:
> > 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.

Even though I was replying to a toy-vs-general-purpose language,
my points were about specific BPF extensions, sending binaries
over HTTPS wasn't on my mind!

In this particular case (backward jumps within the current function),
bytecode would be sent over /dev/bpf by anyone with access (usually
root).

How exactly backward jumps can be tamed isn't that important for this
discussion, the main point is that you can generalise BPF to be closer
to general-purpose bytecode (by adding calls and backward jumps ==
loops) but it won't become a general-purpose bytecode because of timing
constraints (among other things).


Alex

PS some people suggested counting instructions at runtime and
aborting but it's more expensive than counting backward jumps.