On Aug 9, 2013, at 1:44 PM, Thor Lancelot Simon <t...@panix.com> wrote:
> On Fri, Aug 09, 2013 at 09:34:25PM +0100, Mindaugas Rasiukevicius wrote: >> Steven, >> >> Steven Bellovin <s...@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. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
