From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 21:25:31 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 DEC7FA54 for ; Fri, 9 Aug 2013 21:25:31 +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 C838A23C9 for ; Fri, 9 Aug 2013 21:25:31 +0000 (UTC) Received: from ws (localhost [IPv6:::1]) by mail.netbsd.org (Postfix) with SMTP id 1BF5F14A33B; Fri, 9 Aug 2013 21:25:29 +0000 (UTC) Date: Fri, 9 Aug 2013 22:25:09 +0100 From: Mindaugas Rasiukevicius To: Thor Lancelot Simon Subject: Re: BPF_MISC+BPF_COP and BPF_COPX In-Reply-To: <20130809204436.GA3261@panix.com> References: <20130804191310.2FFBB14A152@mail.netbsd.org> <5202693C.50608@netbsd.org> <20130807175548.1528014A21F@mail.netbsd.org> <5203535D.2040508@netbsd.org> <38CDC9BB-09C7-4241-8746-163BD15B80EC@cs.columbia.edu> <20130809203446.428A714A308@mail.netbsd.org> <20130809204436.GA3261@panix.com> X-Mailer: mail(1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20130809212530.1BF5F14A33B@mail.netbsd.org> Cc: tech-net@NetBSD.org, freebsd-net@freebsd.org, guy@alum.mit.edu, darrenr@NetBSD.org, Steven Bellovin 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: Fri, 09 Aug 2013 21:25:31 -0000 Thor Lancelot Simon wrote: > On Fri, Aug 09, 2013 at 09:34:25PM +0100, Mindaugas Rasiukevicius wrote: > > Steven, > > > > Steven Bellovin wrote: > > > There's a one-word summary: *assurance*. With the current design, > > > it's easy to *know* what can happen. With a Turing-complete > > > extension, it isn't. > > > > It is still easy and the concept itself is very simple. I mentioned > > that this extension does not make byte-code Turing-complete and the > > rest is in your control. Darren ignored it. > > Yes, but since the extension makes the program no longer consist solely > of bytecode, it tends to give the impression that the program may now > be, in total, in a Turing-complete language. It blurs the boundary > between the program and its interpreter, by allowing the bytecode to > directly call into the interpreter. Or am I missing something? I think "impression" is the right word here. :) The extension i.e. the coprocessor cannot change the flow of your program. It can inspect the packet in a read-only manner and return couple 32-bit numbers. Nothing really more, unless you are abusing the provided interface and writing some crazy coprocessor functions. However, you can as well write crazy code in tcp_input(). I think we have enough common sense to not do that. > I think what you want to do may be a good idea, in the end, but I do > think it calls for what others are requesting: a real problem statement > and an explanation of why the proposed solution is safer than it would > at first appear. The problem is simple: I want a generic mechanism to offload more complex packet inspection operations, e.g. lookup IP address in some container or walk IPv6 headers and return some offsets. There is no reason why we need a separate instruction for each operation, it can (and I argue that it should) be generic. -- Mindaugas