Date: Fri, 09 Aug 2013 21:09:47 +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: <5204CDFB.6060200@netbsd.org> In-Reply-To: <20130808141819.103DB14A2AA@mail.netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <20130808111501.1974C14A2B0@mail.netbsd.org> <52039B3C.1070509@netbsd.org> <20130808141819.103DB14A2AA@mail.netbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/08/2013 12:17 AM, Mindaugas Rasiukevicius wrote: > Darren Reed <darrenr@netbsd.org> wrote: >> On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote: >>> Darren Reed <darrenr@netbsd.org> wrote: >>>>> >>>>> You do not have to use it. >>>> >>>> I get no choice - it is in the kernel by default. >>>> >>> >>> There is no default coprocessor. Here is your choice: do not call >>> bpf_set_cop(9) and those instructions will effectively be NOPs. >> >> Anyone with the required privileges to run tcpdump can set this >> coprocessor. > > You got it wrong. Sorry if I was not clear, I will try to clarify > it again. Rather than try explaining it across an email thread, maybe the design should be presented fully and accompany a problem description. >> At present it is impossible for there to be an infinite loop because >> it always branches/jumps forward, thus preventing looping behaviour. >> >> It is this very strictness that makes BPF work and worthwhile. >> >> Without that, it may as well be Java or some other byte code language. > > What kind of strictness are you talking about? Previously you were > talking about security, now about the capability of the BPF byte-code. The strictness that makes it impossible for there to be infinite loops (for example.) That strictness also imparts security. > The coprocessor support provides offloading capability. Yes, it does... > If your point was that we should not consider improvements and conserve > the instruction set from 80s, then we simply disagree. :) No, improvements in BPF are required for IPv6, e.g. http://permalink.gmane.org/gmane.network.tcpdump.devel/5141 >> Ok, I'll un-contradict myself: >> it shouldn't be possible for BPF to consist of mneumonics that are >> function calls that work on the packet rather than operations on the >> registers/memory. If I implied that this was ok then I was wrong. > > Can you provide a justification for this? Because then BPF ceases to be a language that can be verified for security, reliability and performance purposes. >> Is it trying to deal with a limitation/problem in npf? > > Not at all. This is to avoid code duplication. It is BPF which has a > limitation and BPF_COP is a clean way (design wise) to address it. Maybe you should start this proposal properly with a problem description and how this solves it. There isn't nearly enough information in what has been presented to properly understand what has been proposed. Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5204CDFB.6060200>