From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 May 2011 15:56:03 +0200 (CEST) Received: from casper.infradead.org ([85.118.1.10]:50926 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1491837Ab1EMNzz convert rfc822-to-8bit (ORCPT ); Fri, 13 May 2011 15:55:55 +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 1QKsqJ-0005lz-16; Fri, 13 May 2011 13:55:47 +0000 Received: by twins (Postfix, from userid 1000) id EB1ED81309F0; Fri, 13 May 2011 15:55:35 +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 , 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: <20110513131800.GA7883@elte.hu> References: <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> <1305292132.2466.26.camel@twins> <20110513131800.GA7883@elte.hu> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Fri, 13 May 2011 15:55:35 +0200 Message-ID: <1305294935.2466.64.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: 29989 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 Cut the microblaze list since its bouncy. On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote: > * Peter Zijlstra wrote: > > > 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. > > Do you mean that one filter returns -EINVAL while the other -EACCES? > > Seems like a non-problem to me, we'd return the first nonzero value. Assuming the first is -EINVAL, what then is the value in computing the -EACCESS? Sounds like a massive waste of time to me. > > 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. > > Do you mean it would be easy to abuse it? What kind of abuse are you most > worried about? I'm not worried about abuse, I'm saying that going by the existing notifier pattern always visiting all entries on the callback list is undesired. > > 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. > > But i suspect this question has been settled, given the fact that even pure > observer events need and already process a chain of events? Am i missing > something about your argument? I'm saying that there's reasons to not use notifiers passive or active. Mostly the whole notifier/indirection muck comes up once you want modules to make use of the thing, because then you need dynamic management of the callback list. (Then again, I'm fairly glad we don't have explicit callbacks in kernel/cpu.c for all the cpu-hotplug callbacks :-) Anyway, I oppose for the existing events to gain an active role. 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 58E071007FD for ; Fri, 13 May 2011 23:56:03 +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: <20110513131800.GA7883@elte.hu> References: <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> <1305292132.2466.26.camel@twins> <20110513131800.GA7883@elte.hu> Content-Type: text/plain; charset="UTF-8" Date: Fri, 13 May 2011 15:55:35 +0200 Message-ID: <1305294935.2466.64.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 , kees.cook@canonical.com, "Serge E. Hallyn" , 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: , Cut the microblaze list since its bouncy. On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote: > * Peter Zijlstra wrote: >=20 > > 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= that at=20 > > > least one failed - and we'd return a failure.=20 > >=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. >=20 > Do you mean that one filter returns -EINVAL while the other -EACCES? >=20 > Seems like a non-problem to me, we'd return the first nonzero value. Assuming the first is -EINVAL, what then is the value in computing the -EACCESS? Sounds like a massive waste of time to me. > > 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. >=20 > Do you mean it would be easy to abuse it? What kind of abuse are you most= =20 > worried about? I'm not worried about abuse, I'm saying that going by the existing notifier pattern always visiting all entries on the callback list is undesired. > > 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: > >=20 > > foo1(bar); > > foo2(bar); > > foo3(bar); > >=20 > > Than: > >=20 > > foo_notifier(bar); > >=20 > > 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. > >=20 > > Its also much faster, no extra memory accesses, no indirect function > > calls, no other muck. >=20 > But i suspect this question has been settled, given the fact that even pu= re=20 > observer events need and already process a chain of events? Am i missing= =20 > something about your argument? I'm saying that there's reasons to not use notifiers passive or active. Mostly the whole notifier/indirection muck comes up once you want modules to make use of the thing, because then you need dynamic management of the callback list. (Then again, I'm fairly glad we don't have explicit callbacks in kernel/cpu.c for all the cpu-hotplug callbacks :-) Anyway, I oppose for the existing events to gain an active role. From mboxrd@z Thu Jan 1 00:00:00 1970 From: peterz@infradead.org (Peter Zijlstra) Date: Fri, 13 May 2011 15:55:35 +0200 Subject: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering In-Reply-To: <20110513131800.GA7883@elte.hu> References: <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> <1305292132.2466.26.camel@twins> <20110513131800.GA7883@elte.hu> Message-ID: <1305294935.2466.64.camel@twins> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Cut the microblaze list since its bouncy. On Fri, 2011-05-13 at 15:18 +0200, Ingo Molnar wrote: > * Peter Zijlstra wrote: > > > 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. > > Do you mean that one filter returns -EINVAL while the other -EACCES? > > Seems like a non-problem to me, we'd return the first nonzero value. Assuming the first is -EINVAL, what then is the value in computing the -EACCESS? Sounds like a massive waste of time to me. > > 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. > > Do you mean it would be easy to abuse it? What kind of abuse are you most > worried about? I'm not worried about abuse, I'm saying that going by the existing notifier pattern always visiting all entries on the callback list is undesired. > > 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. > > But i suspect this question has been settled, given the fact that even pure > observer events need and already process a chain of events? Am i missing > something about your argument? I'm saying that there's reasons to not use notifiers passive or active. Mostly the whole notifier/indirection muck comes up once you want modules to make use of the thing, because then you need dynamic management of the callback list. (Then again, I'm fairly glad we don't have explicit callbacks in kernel/cpu.c for all the cpu-hotplug callbacks :-) Anyway, I oppose for the existing events to gain an active role.