Date: Wed, 7 Aug 2013 18:55:27 +0100 From: Mindaugas Rasiukevicius <rmind@netbsd.org> To: darrenr@netbsd.org Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Message-ID: <20130807175548.1528014A21F@mail.netbsd.org> In-Reply-To: <5202693C.50608@netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Darren Reed <darrenr@netbsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130807175548.1528014A21F>