From owner-freebsd-net@FreeBSD.ORG Fri Aug 9 21:05:38 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 AED036B for ; Fri, 9 Aug 2013 21:05:38 +0000 (UTC) (envelope-from mouse@Chip.Rodents-Montreal.ORG) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by mx1.freebsd.org (Postfix) with ESMTP id 5533722D5 for ; Fri, 9 Aug 2013 21:05:38 +0000 (UTC) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id RAA26682; Fri, 9 Aug 2013 17:01:23 -0400 (EDT) Date: Fri, 9 Aug 2013 17:01:23 -0400 (EDT) From: Mouse Message-Id: <201308092101.RAA26682@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Fri, 9 Aug 2013 16:55:10 -0400 (EDT) To: tech-net@NetBSD.org Subject: Re: BPF_MISC+BPF_COP and BPF_COPX 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> Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 21:05:38 -0000 > 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