Re: BPF memstore and bpf_validate_ext()

[Alexander Nasonov <alnsn%yandex.ru@localhost>]

Mindaugas Rasiukevicius wrote:
> Alexander Nasonov <alnsn%yandex.ru@localhost> wrote:
> > My point is that you mix "argument pack" with something else. They
> > should be separeted.
> 
> The external memory store can be used as an argument (and the initial
> values determined as proposed in this thread).  If you want, we can pass
> it as a third argument, I just think it is a pointless indirection level.
> Would even need extra wrapping i.e. more work in bpfjit, but if you want
> that separated - fine.

I'll tell you more. Mixing mem with arguments will not only save
me one register/one indirection level but it will allow to use
memory addressing. It's very attractive solution from a performance
perspective. But it's clearly a hack and I don't want to have hacks
in public API.

> > I already offered to support SLJIT_FAST_CALL copfuncs in bpfjit.
> > They're much faster than regular copfuncs.  But that's mean you
> > will need to emit sljit code and you will have a limited number of
> > sljit registers and all other limitations of sljit. You still should
> > be able to copy data from auxiliary argument to memstore and you
> > can do it quite fast. <...>
> 
> That is great, but we are going circles here.  If a program just needs
> some values stored in the memory store - why would you create a COP to
> get few integers instead of simply letting the caller to pass them.  It
> is the thing which actually has those numbers.

What if your program "just needs" something else? Does it mean we have
to add a new feature to bpf? No. We have to stop somewhere. BPF_COP
is powerful enough for getting external data. It's a bit slower but I
can give you SLJIT_FAST_CALL interface. If it's still slow for you,
you should stop using sljit and consider other alternatives.

> > It's easy to
> > suggest to have a flag but it's actually a lot or work. You need to
> > write several lines of C code to generate a single instruction.
> 
> The flag would basically say "treat the memstore as internal i.e. just
> do all the optimisations, because I assure there are no side effects".
> It is a green light for what you said you already want to implement.
> That would be one-liner check or I miss something?

Ok, with my recent change on github, it's indeed one-line change
but having two different modes can introduce subtle bugs. If you
forget to set the mode properly, you may have a situation when your
memory is in a bad state only for packets of length 131 (or whatever)
and it's consistent for all other lengths.
I'm as a maintainer of bpfjit is responsible for a robust public
interface.

Alex