From owner-freebsd-net@FreeBSD.ORG Wed Aug 7 17:55:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8F6CF3EA for ; Wed, 7 Aug 2013 17:55:49 +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 60C062CBD for ; Wed, 7 Aug 2013 17:55:49 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 1528014A21F; Wed, 7 Aug 2013 17:55:47 +0000 (UTC) Date: Wed, 7 Aug 2013 18:55:27 +0100 From: Mindaugas Rasiukevicius To: darrenr@netbsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <5202693C.50608@netbsd.org> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130807175548.1528014A21F@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: Wed, 07 Aug 2013 17:55:49 -0000 Darren Reed wrote: > > > > 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". > > No. > You do not have to use it. > 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. > > This change brakes the BPF security model because now the BPF program > is calling out to some random function as part of the packet matching. BPF byte-code can still be verified. You cannot call random functions, the functions are predetermined and cannot change during the life-cycle. There is a difference. However, it is as secure as calling any other function in the kernel on packet transmission. You can make a bug in your function, but you can as well make it in tcp_input(). > > 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. > > Then add BPF instructions to manipulate address sets (add, remove, lookup) > and pick a datastore to use to support it. How adding specialised random instructions is better than having a generic mechanism? You mean BPF_SOME_LOOKUP calling some_lookup() suddenly becomes more secure than BPF_MISC+BPF_COP calling the same some_lookup()? > In doing that the benefits can thereafter be applied to other programs > (such as tcpdump) that have a large list of entities that need to be > matched against. They can grow such support using coprocessor. There is no reason why there could not be a generic (or custom) coprocessor which you could simply modload, if you trust it (or blacklist if you do not). -- Mindaugas