Re: BPF_MISC+BPF_COP and BPF_COPX

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

Darren Reed <darrenr%netbsd.org@localhost> wrote:
> >
> > I would like propose new BPF instructions for the misc category: BPF_COP
> > and BPF_COPX.  It would provide a capability of calling an external
> > function - think of BPF "coprocessor".
> 
> No.
> 

You do not have to use it.

> A BPF program is an entity that can be verified as correct from a
> security perspective.It is also self contained and requires no
> external references in order to understand.
> 
> This change brakes the BPF security model because now the BPF program
> is calling out to some random function as part of the packet matching.

BPF byte-code can still be verified.  You cannot call random functions,
the functions are predetermined and cannot change during the life-cycle.
There is a difference.  However, it is as secure as calling any other
function in the kernel on packet transmission.  You can make a bug in
your function, but you can as well make it in tcp_input().

> > It provides us a capability to offload more complex packet processing.
> > My primary user would be NPF in NetBSD, e.g. one of the operations is to
> > lookup an IP address in a table/ipset.
> 
> Then add BPF instructions to manipulate address sets (add, remove, lookup)
> and pick a datastore to use to support it.

How adding specialised random instructions is better than having a generic
mechanism?  You mean BPF_SOME_LOOKUP calling some_lookup() suddenly becomes
more secure than BPF_MISC+BPF_COP calling the same some_lookup()?

> In doing that the benefits can thereafter be applied to other programs
> (such as tcpdump) that have a large list of entities that need to be
> matched against.

They can grow such support using coprocessor.  There is no reason why
there could not be a generic (or custom) coprocessor which you could
simply modload, if you trust it (or blacklist if you do not).

-- 
Mindaugas