Date: Sun, 4 Aug 2013 20:55:18 +0100 From: Mindaugas Rasiukevicius <rmind@netbsd.org> To: Rui Paulo <rpaulo@felyko.com> Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Message-ID: <20130804195538.C87A614A135@mail.netbsd.org> In-Reply-To: <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Rui Paulo <rpaulo@felyko.com> wrote: > > > > Comments? > > > Why do you need this in the first place? 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. > Are you sure this is a safe design? Adding this functionality to BPF > makes me a little nervous as an error in the implementation leads to > kernel code execution (I could be able to call random kernel functions). This is functionality is for a custom use of BPF. There would be no coprocessor by default and the instruction would essentially be a NOP. Perhaps I was not clear on bpf_set_cop(9) - it is a kernel routine, so the user would be a kernel subsystem which has a full control over the functions it provides. The functions are predetermined, not random. -- Mindaugas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130804195538.C87A614A135>