From owner-freebsd-net@FreeBSD.ORG Thu Aug 8 13:17:59 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 9EC3D904 for ; Thu, 8 Aug 2013 13:17:59 +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 5A5CC219A for ; Thu, 8 Aug 2013 13:17:59 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AA7C220DBB; Thu, 8 Aug 2013 09:17:57 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Thu, 08 Aug 2013 09:17:57 -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=2/ATuETxOA7SMDbTu3bvZK wD92k=; b=kdL+BGSUS4BGwbXOo2P3nPGZb2i2AFHdU89fnCXUM1ZyArCR8HDQi7 khlxyYMLnORQTkJRy2D9PY1G6w2qYRdoiD7D4GF0gqLRFG0AE7c2el80NyCrtFL8 0W3E+uEhtTycX7gdLfw/1mrZ60FiZwEyKDak9hzKaHHVhpC9cTL08= X-Sasl-enc: qMdkMLLxgLi2CG89jHqkzNIKc/Cqt2IOxtpqi6TgOCu5 1375967877 Received: from [172.20.10.2] (unknown [110.144.139.235]) by mail.messagingengine.com (Postfix) with ESMTPA id E8DCD6801B8; Thu, 8 Aug 2013 09:17:55 -0400 (EDT) Message-ID: <52039B3C.1070509@netbsd.org> Date: Thu, 08 Aug 2013 23:21:00 +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> <5203535D.2040508@netbsd.org> <20130808111501.1974C14A2B0@mail.netbsd.org> In-Reply-To: <20130808111501.1974C14A2B0@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 13:17:59 -0000 On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote: > 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. Anyone with the required privileges to run tcpdump can set this coprocessor. >> <...> >> >> 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. >> ... > 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*. 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. >>>> 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. 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. Have you presented why this approach that you've embarked on is required and others do not work? Is it trying to deal with a limitation/problem in npf? Darren