I think it's slightly unfair to propose a new extension for BPF without any in-tree users.
Is this going to be some external commercial coprocessor? -adrian On 4 August 2013 12:55, Mindaugas Rasiukevicius <rm...@netbsd.org> wrote: > Rui Paulo <rpa...@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 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
