From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 08:11:20 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 A49D81C7 for ; Thu, 8 Aug 2013 08:11:20 +0000 (UTC) (envelope-from darrenr@netbsd.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 778E32D7C for ; Thu, 8 Aug 2013 08:11:20 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7040D2112A; Thu, 8 Aug 2013 04:11:18 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 08 Aug 2013 04:11:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=36lLe/ZDpKY8rVnizEEzVA 8j1Gk=; b=dATFPscFGAUTgljfkltEeTAqUuYyq3mRXe6xHq2v/DNuBjgvDcVWn/ SNdBD8hoW65vXqVSTN6Lc2m9eZsqLSGvCnmG6wKX5arTF+6H8dt4jt9gcGL83xUN yryH2OaH4MnPstermM/TRWSh/7LYnXqUR9901TKTlNe1YNsynhwHQ= X-Sasl-enc: Rqzd9Vye2fmaWVrLMbwD4b4HbWwjCsAIY3zKiHesqI/B 1375949477 Received: from [172.20.10.2] (unknown [110.144.14.48]) by mail.messagingengine.com (Postfix) with ESMTPA id 55DD8680106; Thu, 8 Aug 2013 04:11:16 -0400 (EDT) Message-ID: <5203535D.2040508@netbsd.org> Date: Thu, 08 Aug 2013 18:14:21 +1000 From: Darren Reed Organization: NetBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> In-Reply-To: <20130807175548.1528014A21F@mail.netbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 Reply-To: darrenr@netbsd.org 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 08:11:20 -0000 On 8/08/2013 3:55 AM, Mindaugas Rasiukevicius wrote: > 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. I get no choice - it is in the kernel by default. >> 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(). 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. >>> 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()? See below. 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 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 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? 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. > The BPF design has some serious limitations for modern network > protocols. For example, the forward-jump-only property makes it > impossible to write rules for protocols with arbitrary header > composition. While it is not desirable to completely remove this > restriction, the proposal could help to deal with many of the > interesting case efficently. Correct. The forward jumping only aspect is an important attribute of BPF as it bounds the amount of time that the system can spend on processing the packet. Given that BPF opcodes are evaluated in the hot patch of packet processing, that kind of guarantee is very important. I think your reference here to arbitrary header ordering is in reference to IPv6 - which actually does have some rules about in which order headers can be found. Just as IPv4 has a special instruction with which to find the start of a transport header, I see no reason why something similar shouldn't exist for IPv6. The challenge becomes to think of processing the packet differently and how the relationship between BPF and the packet dictates what instructions are necessary. Darren