Date: Fri, 9 Aug 2013 17:01:23 -0400 (EDT) From: Mouse <mouse@Rodents-Montreal.ORG> To: tech-net@NetBSD.org Cc: freebsd-net@freebsd.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX Message-ID: <201308092101.RAA26682@Chip.Rodents-Montreal.ORG> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Like pretty much any bytecode, BPF bytecode is _nothing but_ direct calls into the interpreter. Except for psychological effects, this whole modification is nothing but reserving a particular range of bytecodes for per-(kernel-)user-of-bpf custom uses. Mind you, psychological effects can be important. But I think the biggest psychological effect here is the one that is causing most of the trouble: the way this is named and was described make it sound as though it is more general, and less safe, than it actually is. It bothered me too at first, but when it was clarified that a given COP function is not automatically available to every BPF program in the system just because it's available to one, I've been unable to come up with a reason to dislike this that I can actually defend to myself. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201308092101.RAA26682>