From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 11:15:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 80F894DC for ; Thu, 8 Aug 2013 11:15:02 +0000 (UTC) (envelope-from rmind@netbsd.org) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:4f8:3:7::25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6CF162905 for ; Thu, 8 Aug 2013 11:15:02 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 1974C14A2B0; Thu, 8 Aug 2013 11:15:00 +0000 (UTC) Date: Thu, 8 Aug 2013 12:14:42 +0100 From: Mindaugas Rasiukevicius To: darrenr@netbsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX 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> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130808111501.1974C14A2B0@mail.netbsd.org> Cc: tech-net@netbsd.org, guy@alum.mit.edu, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 11:15:02 -0000 Darren Reed 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