Date: Sun, 4 Aug 2013 12:31:38 -0700 From: Rui Paulo <rpaulo@felyko.com> 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: <9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7@felyko.com> In-Reply-To: <20130804191310.2FFBB14A152@mail.netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Aug 2013, at 12:12, Mindaugas Rasiukevicius <rmind@netbsd.org> = wrote: > Hello, >=20 > 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". The argument for BPF_COP is an > index to a pre-loaded array of function pointers. BPF_COPX takes the > function index from the register X rather than a constant. >=20 > BPF_STMT(BPF_MISC+BPF_COP, 0), /* A <- funcs[0](...) */ >=20 > typedef uint32_t(*bpf_copfunc_t)(struct mbuf *pkt, > uint32_t A, uint32_t *M); >=20 > int bpf_set_cop(bpf_ctx_t *c, bpf_copfunc_t funcs[], size_t n); >=20 > The arguments passed to a called function would be the packet, = accumulator > and the memory store. The return value would be stored in the = accumulator > and the register X would be reset to 0. Note that the function may = also > change the memory store. If the function index is out of range, then = the > register X would be set to 0xffffffff. >=20 > Note that bpf_filter(9) would need to take some context structure = (which is > preferable in general). >=20 > Comments? Why do you need this in the first place?=20 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). -- Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9813E50B-C557-4FE1-BADF-A2CFFCBB8BD7>