Re: BPF memstore and bpf_validate_ext()

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

Mindaugas Rasiukevicius wrote:
> Also, it was you who proposed sljit.

Proposed for what? I implemented bpfjit using sljit if that's what
you mean. I offered you a help with implementing jit compiler for
npfcode. It was your idea to add COP/COPX and I agreed to implement
a support for it in bpfjit. I never agreed on implementing external
memory.

> It can optimise *most* practical
> cases (80-20 rule) and I am happy with that.  I do not understand why
> are you concerned about those rare/unusual cases.  Do you have some
> particular application in mind?  Something else than in our tree?

I don't have any application in mind but I don't understand why are you
pushing two extentions to bpf solely to get performance benefit for
your cases and you don't care that bpf looses performance even if there
are no cop instructions in a program at all.

> We can pass the memstore pointer as a separate argument (it would be
> three arguments, fine for sljit), but what's the point..

My point is that you mix "argument pack" with something else. They
should be separeted.

> Why are you ignoring the fact that your optimisations can still be added
> and be effective?  I already suggested - we can add a flag to indicate that
> the caller does not care about the result in the memory store.

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.

You didn't respond to me about it. If you ingored it because you don't
want to deal with sljit than you're pulling a blanket. 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.

I don't want to maintain two different modes of code generation.
If you want this flag, go ahead, write the code, write the tests
and everyone will be happy.


> Moreover,
> the usual byte-code produced by tcpdump/pcap does not even use the memory
> store so you optimisations would most of the time be applicable anyway!

Maybe in this case. I don't know all use cases. There are some
IDS/IPS that use bpf but I never looked at them.

In any case, this functionality will have to be tested.

Alex