From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 May 2011 15:09:31 +0200 (CEST) Received: from casper.infradead.org ([85.118.1.10]:43143 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1491818Ab1EMNJY convert rfc822-to-8bit (ORCPT ); Fri, 13 May 2011 15:09:24 +0200 Received: from j77219.upc-j.chello.nl ([24.132.77.219] helo=twins) by casper.infradead.org with esmtpsa (Exim 4.72 #1 (Red Hat Linux)) id 1QKs75-0004sW-Vs; Fri, 13 May 2011 13:09:04 +0000 Received: by twins (Postfix, from userid 1000) id C3F3281309F0; Fri, 13 May 2011 15:08:52 +0200 (CEST) Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering From: Peter Zijlstra To: Ingo Molnar Cc: James Morris , Will Drewry , linux-kernel@vger.kernel.org, Steven Rostedt , Frederic Weisbecker , Eric Paris , kees.cook@canonical.com, agl@chromium.org, "Serge E. Hallyn" , Ingo Molnar , Andrew Morton , Tejun Heo , Michal Marek , Oleg Nesterov , Roland McGrath , Jiri Slaby , David Howells , Russell King , Michal Simek , Ralf Baechle , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , linux390@de.ibm.com, Paul Mundt , "David S. Miller" , Thomas Gleixner , "H. Peter Anvin" , x86@kernel.org, linux-arm-kernel@lists.infradead.org, microblaze-uclinux@itee.uq.edu.au, linux-mips@linux-mips.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, Linus Torvalds In-Reply-To: <20110513125452.GD3924@elte.hu> References: <1305169376-2363-1-git-send-email-wad@chromium.org> <20110512074850.GA9937@elte.hu> <20110512130104.GA2912@elte.hu> <20110513121034.GG21022@elte.hu> <1305289146.2466.8.camel@twins> <20110513122646.GA3924@elte.hu> <1305290370.2466.14.camel@twins> <1305290612.2466.17.camel@twins> <20110513125452.GD3924@elte.hu> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Fri, 13 May 2011 15:08:52 +0200 Message-ID: <1305292132.2466.26.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 29987 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: peterz@infradead.org Precedence: bulk X-list: linux-mips On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: > I think the sanest semantics is to run all active callbacks as well. > > For example if this is used for three stacked security policies - as if 3 LSM > modules were stacked at once. We'd call all three, and we'd determine that at > least one failed - and we'd return a failure. But that only works for boolean functions where you can return the multi-bit-or of the result. What if you need to return the specific error code. Also, there's bound to be other cases where people will want to employ this, look at all the various notifier chain muck we've got, it already deals with much of this -- simply because users need it. Then there's the whole indirection argument, if you don't need indirection, its often better to not use it, I myself much prefer code to look like: foo1(bar); foo2(bar); foo3(bar); Than: foo_notifier(bar); Simply because its much clearer who all are involved without me having to grep around to see who registers for foo_notifier and wth they do with it. It also makes it much harder to sneak in another user, whereas its nearly impossible to find new notifier users. Its also much faster, no extra memory accesses, no indirect function calls, no other muck. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id AAA97B6EFF for ; Fri, 13 May 2011 23:09:33 +1000 (EST) Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering From: Peter Zijlstra To: Ingo Molnar In-Reply-To: <20110513125452.GD3924@elte.hu> References: <1305169376-2363-1-git-send-email-wad@chromium.org> <20110512074850.GA9937@elte.hu> <20110512130104.GA2912@elte.hu> <20110513121034.GG21022@elte.hu> <1305289146.2466.8.camel@twins> <20110513122646.GA3924@elte.hu> <1305290370.2466.14.camel@twins> <1305290612.2466.17.camel@twins> <20110513125452.GD3924@elte.hu> Content-Type: text/plain; charset="UTF-8" Date: Fri, 13 May 2011 15:08:52 +0200 Message-ID: <1305292132.2466.26.camel@twins> Mime-Version: 1.0 Cc: linux-mips@linux-mips.org, linux-sh@vger.kernel.org, Frederic Weisbecker , Heiko Carstens , Oleg Nesterov , David Howells , Paul Mackerras , Eric Paris , "H. Peter Anvin" , sparclinux@vger.kernel.org, Jiri Slaby , linux-s390@vger.kernel.org, Russell King , x86@kernel.org, James Morris , Linus Torvalds , Ingo Molnar , linux-arm-kernel@lists.infradead.org, kees.cook@canonical.com, "Serge E. Hallyn" , microblaze-uclinux@itee.uq.edu.au, Steven Rostedt , Martin Schwidefsky , Thomas Gleixner , Roland McGrath , Michal Marek , Michal Simek , Will Drewry , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Ralf Baechle , Paul Mundt , Tejun Heo , linux390@de.ibm.com, Andrew Morton , agl@chromium.org, "David S. Miller" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: > I think the sanest semantics is to run all active callbacks as well. >=20 > For example if this is used for three stacked security policies - as if 3= LSM=20 > modules were stacked at once. We'd call all three, and we'd determine tha= t at=20 > least one failed - and we'd return a failure.=20 But that only works for boolean functions where you can return the multi-bit-or of the result. What if you need to return the specific error code. Also, there's bound to be other cases where people will want to employ this, look at all the various notifier chain muck we've got, it already deals with much of this -- simply because users need it. Then there's the whole indirection argument, if you don't need indirection, its often better to not use it, I myself much prefer code to look like: foo1(bar); foo2(bar); foo3(bar); Than: foo_notifier(bar); Simply because its much clearer who all are involved without me having to grep around to see who registers for foo_notifier and wth they do with it. It also makes it much harder to sneak in another user, whereas its nearly impossible to find new notifier users. Its also much faster, no extra memory accesses, no indirect function calls, no other muck. From mboxrd@z Thu Jan 1 00:00:00 1970 From: peterz@infradead.org (Peter Zijlstra) Date: Fri, 13 May 2011 15:08:52 +0200 Subject: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering In-Reply-To: <20110513125452.GD3924@elte.hu> References: <1305169376-2363-1-git-send-email-wad@chromium.org> <20110512074850.GA9937@elte.hu> <20110512130104.GA2912@elte.hu> <20110513121034.GG21022@elte.hu> <1305289146.2466.8.camel@twins> <20110513122646.GA3924@elte.hu> <1305290370.2466.14.camel@twins> <1305290612.2466.17.camel@twins> <20110513125452.GD3924@elte.hu> Message-ID: <1305292132.2466.26.camel@twins> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, 2011-05-13 at 14:54 +0200, Ingo Molnar wrote: > I think the sanest semantics is to run all active callbacks as well. > > For example if this is used for three stacked security policies - as if 3 LSM > modules were stacked at once. We'd call all three, and we'd determine that at > least one failed - and we'd return a failure. But that only works for boolean functions where you can return the multi-bit-or of the result. What if you need to return the specific error code. Also, there's bound to be other cases where people will want to employ this, look at all the various notifier chain muck we've got, it already deals with much of this -- simply because users need it. Then there's the whole indirection argument, if you don't need indirection, its often better to not use it, I myself much prefer code to look like: foo1(bar); foo2(bar); foo3(bar); Than: foo_notifier(bar); Simply because its much clearer who all are involved without me having to grep around to see who registers for foo_notifier and wth they do with it. It also makes it much harder to sneak in another user, whereas its nearly impossible to find new notifier users. Its also much faster, no extra memory accesses, no indirect function calls, no other muck.