From owner-freebsd-net@FreeBSD.ORG  Fri Aug  9 21:32:15 2013
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 D9085E7
 for <freebsd-net@freebsd.org>; Fri,  9 Aug 2013 21:32:15 +0000 (UTC)
 (envelope-from matt@3am-software.com)
Received: from panix.3am-software.com (panix.3am-software.com [166.84.6.62])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.freebsd.org (Postfix) with ESMTPS id 86275245B
 for <freebsd-net@freebsd.org>; Fri,  9 Aug 2013 21:32:15 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1])
 by panix.3am-software.com (Postfix) with ESMTP id 9035D278405;
 Fri,  9 Aug 2013 17:39:21 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: BPF_MISC+BPF_COP and BPF_COPX
From: Matt Thomas <matt@3am-software.com>
In-Reply-To: <20130809204436.GA3261@panix.com>
Date: Fri, 9 Aug 2013 14:23:04 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <D30E8B6A-A13F-4889-BA14-25D1955D0E97@3am-software.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>
To: Thor Lancelot Simon <tls@panix.com>
X-Mailer: Apple Mail (2.1508)
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
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2013 21:32:15 -0000


On Aug 9, 2013, at 1:44 PM, Thor Lancelot Simon <tls@panix.com> wrote:

> On Fri, Aug 09, 2013 at 09:34:25PM +0100, Mindaugas Rasiukevicius wrote:
>> Steven,
>> 
>> Steven Bellovin <smb@cs.columbia.edu> 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?

You already have to trust the interpreter, you are now extending that
trust to who invoked the interpreter.  One aspect of all this is
that by allowing the invoker to setup the initial register set used
by the BPF program and then having access to it after it returns, you
can have BPF do more sophisticated things than just returning a scalar.

The possibility of the COP/COPX functions doing bad things is over
wrought.  It makes the assumption of avoiding BPF and then coding
everything is safer than using BPF and COP/COPX functions.