Re: BPF_MISC+BPF_COP and BPF_COPX

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> On Fri, Aug 09, 2013 at 09:34:25PM +0100, Mindaugas Rasiukevicius wrote:
> > Steven,
> > 
> > Steven Bellovin <smb%cs.columbia.edu@localhost> wrote:
> > > There's a one-word summary: *assurance*.  With the current design,
> > > it's easy to *know* what can happen.  With a Turing-complete
> > > extension, it isn't.
> > 
> > It is still easy and the concept itself is very simple.  I mentioned
> > that this extension does not make byte-code Turing-complete and the
> > rest is in your control.  Darren ignored it.
> 
> Yes, but since the extension makes the program no longer consist solely
> of bytecode, it tends to give the impression that the program may now
> be, in total, in a Turing-complete language.  It blurs the boundary
> between the program and its interpreter, by allowing the bytecode to
> directly call into the interpreter.  Or am I missing something?

I think "impression" is the right word here. :)  The extension i.e. the
coprocessor cannot change the flow of your program.  It can inspect the
packet in a read-only manner and return couple 32-bit numbers.  Nothing
really more, unless you are abusing the provided interface and writing
some crazy coprocessor functions.  However, you can as well write crazy
code in tcp_input().  I think we have enough common sense to not do that.

> I think what you want to do may be a good idea, in the end, but I do
> think it calls for what others are requesting: a real problem statement
> and an explanation of why the proposed solution is safer than it would
> at first appear.

The problem is simple: I want a generic mechanism to offload more complex
packet inspection operations, e.g. lookup IP address in some container or
walk IPv6 headers and return some offsets.  There is no reason why we need
a separate instruction for each operation, it can (and I argue that it
should) be generic.

-- 
Mindaugas