Re: BPF_MISC+BPF_COP and BPF_COPX

[Matt Thomas <matt%3am-software.com@localhost>]

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

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