Date: Thu, 08 Aug 2013 18:14:21 +1000 From: Darren Reed <darrenr@netbsd.org> To: Mindaugas Rasiukevicius <rmind@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: <5203535D.2040508@netbsd.org> In-Reply-To: <20130807175548.1528014A21F@mail.netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/08/2013 3:55 AM, Mindaugas Rasiukevicius wrote: > 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. I get no choice - it is in the kernel by default. >> 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(). No. It's not about calling a function, it is about proving the BPF program is correct and secure. BPF today is essentially assembly language operations that are all easily tested and verified. >>> 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()? See below. On 8/08/2013 5:18 AM, Joerg Sonnenberger wrote: > On Thu, Aug 08, 2013 at 01:35:24AM +1000, Darren Reed wrote: >> 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. > > How is this relevant for the discussion? It is important to understand what BPF is before making changes to it. >>> 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 is that more useful than the proposal? Actually, add/remove are not instructions for the BPF language, only lookup. Add, remove, etc, would be handled in the usual manner. How is that more useful? The capability of the opcodes is programmed into the BPF program, not through some external reference. A BPF program generated on Linux is just as valid as on Solaris or NetBSD. Whilst that may be meaningless because nobody copies BPF programs around (in byte code format), this would open a door on developing specialised behaviour for "my platform" that isn't present elsewhere. This then diminishes the value of BPF. > The BPF design has some serious limitations for modern network > protocols. For example, the forward-jump-only property makes it > impossible to write rules for protocols with arbitrary header > composition. While it is not desirable to completely remove this > restriction, the proposal could help to deal with many of the > interesting case efficently. Correct. The forward jumping only aspect is an important attribute of BPF as it bounds the amount of time that the system can spend on processing the packet. Given that BPF opcodes are evaluated in the hot patch of packet processing, that kind of guarantee is very important. I think your reference here to arbitrary header ordering is in reference to IPv6 - which actually does have some rules about in which order headers can be found. Just as IPv4 has a special instruction with which to find the start of a transport header, I see no reason why something similar shouldn't exist for IPv6. The challenge becomes to think of processing the packet differently and how the relationship between BPF and the packet dictates what instructions are necessary. Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5203535D.2040508>