From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 21:02:12 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 0F9C3DFE for ; Fri, 9 Aug 2013 21:02:12 +0000 (UTC) (envelope-from tls@panix.com) Received: from l2mail1.panix.com (l2mail1.panix.com [166.84.1.75]) by mx1.freebsd.org (Postfix) with ESMTP id AED562286 for ; Fri, 9 Aug 2013 21:02:11 +0000 (UTC) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by l2mail1.panix.com (Postfix) with ESMTP id 772C7128 for ; Fri, 9 Aug 2013 16:44:43 -0400 (EDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mailbackend.panix.com (Postfix) with ESMTP id 4679428F6F; Fri, 9 Aug 2013 16:44:37 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 415) id 28CAE242E2; Fri, 9 Aug 2013 16:44:37 -0400 (EDT) Date: Fri, 9 Aug 2013 16:44:37 -0400 From: Thor Lancelot Simon To: Mindaugas Rasiukevicius Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130809203446.428A714A308@mail.netbsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) 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:02:12 -0000 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 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. Thor