Date: Thu, 8 Aug 2013 12:14:42 +0100 From: Mindaugas Rasiukevicius <rmind@netbsd.org> To: darrenr@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: <20130808111501.1974C14A2B0@mail.netbsd.org> In-Reply-To: <5203535D.2040508@netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > <...> > > 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. > > <...> > > 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 is *your* understanding with a premise you just came up. I do not think that your premise is universally accepted. The reason why we have bpf_validate(9) is to ensure that the byte-code cannot cause any harm to the kernel (whether it is an infinite loop, a crash or any other security vulnerability), because it is passed from the *user*. The fundamental difference is that the coprocessor comes from the *kernel*. We tend to trust that the kernel is not self-harming and compilers do constructive job. We cannot validate that (unless you want to challenge Turing's halting problem), but the point being is that we do not need to. > >> 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? You contradict yourself here. It still calls some "external reference" which you are arguing against. > 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. When I was thinking of BPF_COP/BPF_COPX, I was thinking of MIPS. The capability of the opcodes does not have to be programmed into the BPF program. You still have a core set of BPF instructions which will work everywhere and there is a reason why we have BPF_MISC. I can understand the concern about platforms implementing different behaviour, but your proposal of adding an instruction for every specific operation is not going to help. It is a question of agreement (hence CC freebsd-net). -- Mindaugas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130808111501.1974C14A2B0>