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

[Vadim Goncharov <vadimnuclight%gmail.com@localhost>]

On Tue, 10 Sep 2024 21:00:14 +0100
Alexander Nasonov <alnsn%yandex.ru@localhost> wrote:

> 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).

In current BPF64 spec I've made loops without backward jumps - by calls
(actually, this, with return codes, is a trick from Tcl/Tk). This
allows loop body size to be not limited by 8 or even 16 bits, which was
reported as a limiting pain when working with eBPF.

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

I'm including runtime limit into BPF64 as safety belt but not as
counting instructions but by measuring time, e.g. getmicrouptime(9).
This should not be a performance problem if done only on stack
boundaries - that is, only on BPF_CALL/BPF_EXIT, as inside given frame
there are no backward jumps and so it is guaranteed to run until next
check point. Better if it would be just variable read like `time_uptime`
(no atomicity needed) but I don't know elegant way to access such value
with enough resolution without breaking KPI.

-- 
WBR, @nuclight