[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BPF_MISC+BPF_COP and BPF_COPX
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".
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).
Main Index |
Thread Index |