From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 11:06:43 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 EF3DDD30 for ; Fri, 9 Aug 2013 11:06:42 +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 A880420B7 for ; Fri, 9 Aug 2013 11:06:42 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 2BC9320D4D; Fri, 9 Aug 2013 07:06:41 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 09 Aug 2013 07:06:41 -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=xvdofQoH5aSdgvUG4li5n9 ATn2s=; b=tbn55rEA/YCCOIgsu+IKKxu7xP/2QgZN4y64prx0r5zLlboI4SBzdc OegA8Mj5bcem6ac2NRUWKJOKUrgBFGlZVnQv8qFDV0CG6h7bEfekGRtvF+BkVbBD J3OiTetO1l0X5o8qDU8DPI1iEcQ+hp9xQnArY2yQFt8uW5trIduFI= X-Sasl-enc: OSLreD7EY6GH0HYJzqZn3Yh/ODtni49lWMNAc5qCIohY 1376046400 Received: from [172.20.10.2] (unknown [58.171.193.197]) by mail.messagingengine.com (Postfix) with ESMTPA id 67267C00E82; Fri, 9 Aug 2013 07:06:39 -0400 (EDT) Message-ID: <5204CDFB.6060200@netbsd.org> Date: Fri, 09 Aug 2013 21:09:47 +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> <52039B3C.1070509@netbsd.org> <20130808141819.103DB14A2AA@mail.netbsd.org> In-Reply-To: <20130808141819.103DB14A2AA@mail.netbsd.org> Content-Type: text/plain; charset=UTF-8 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: Fri, 09 Aug 2013 11:06:43 -0000 On 9/08/2013 12:17 AM, Mindaugas Rasiukevicius wrote: > Darren Reed wrote: >> 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. > > You got it wrong. Sorry if I was not clear, I will try to clarify > it again. Rather than try explaining it across an email thread, maybe the design should be presented fully and accompany a problem description. >> 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. > > What kind of strictness are you talking about? Previously you were > talking about security, now about the capability of the BPF byte-code. The strictness that makes it impossible for there to be infinite loops (for example.) That strictness also imparts security. > The coprocessor support provides offloading capability. Yes, it does... > If your point was that we should not consider improvements and conserve > the instruction set from 80s, then we simply disagree. :) No, improvements in BPF are required for IPv6, e.g. http://permalink.gmane.org/gmane.network.tcpdump.devel/5141 >> 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. > > Can you provide a justification for this? Because then BPF ceases to be a language that can be verified for security, reliability and performance purposes. >> Is it trying to deal with a limitation/problem in npf? > > Not at all. This is to avoid code duplication. It is BPF which has a > limitation and BPF_COP is a clean way (design wise) to address it. Maybe you should start this proposal properly with a problem description and how this solves it. There isn't nearly enough information in what has been presented to properly understand what has been proposed. Darren