From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 May 2011 14:55:30 +0200 (CEST) Received: from mx3.mail.elte.hu ([157.181.1.138]:43698 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1491829Ab1EMMzZ (ORCPT ); Fri, 13 May 2011 14:55:25 +0200 Received: from elvis.elte.hu ([157.181.1.14]) by mx3.mail.elte.hu with esmtp (Exim) id 1QKrtP-0003SP-7l from ; Fri, 13 May 2011 14:55:00 +0200 Received: by elvis.elte.hu (Postfix, from userid 1004) id D7D583E233D; Fri, 13 May 2011 14:54:50 +0200 (CEST) Date: Fri, 13 May 2011 14:54:52 +0200 From: Ingo Molnar To: Peter Zijlstra 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 Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1305290612.2466.17.camel@twins> User-Agent: Mutt/1.5.20 (2009-08-17) Received-SPF: neutral (mx3: 157.181.1.14 is neither permitted nor denied by domain of elte.hu) client-ip=157.181.1.14; envelope-from=mingo@elte.hu; helo=elvis.elte.hu; X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.3.1 -2.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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: 29986 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: mingo@elte.hu Precedence: bulk X-list: linux-mips * Peter Zijlstra wrote: > On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote: > > > > > event_vfs_getname(result); > > > result = check_event_vfs_getname(result); > > Another fundamental difference is how to treat the callback chains for > these two. > > Observers won't have a return value and are assumed to never fail, > therefore we can always call every entry on the callback list. > > Active things otoh do have a return value, and thus we need to have > semantics that define what to do with that during callback iteration, > when to continue and when to break. Thus for active elements its > impossible to guarantee all entries will indeed be called. 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. Even if the first one failed already we'd still want to trigger *all* the failures, because security policies like to know when they have triggered a failure (regardless of other active policies) and want to see that failure event (if they are logging such events). So to me this looks pretty similar to observer callbacks as well, it's the natural extension to an observer callback chain. Observer callbacks are simply constant functions (to the caller), those which never return failure and which never modify any of the parameters. It's as if you argued that there should be separate syscalls/facilities for handling readonly files versus handling read/write files. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3.mail.elte.hu (mx3.mail.elte.hu [157.181.1.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 7C24EB6F08 for ; Fri, 13 May 2011 22:55:36 +1000 (EST) Date: Fri, 13 May 2011 14:54:52 +0200 From: Ingo Molnar To: Peter Zijlstra Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1305290612.2466.17.camel@twins> 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: , * Peter Zijlstra wrote: > On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote: > > > > > event_vfs_getname(result); > > > result = check_event_vfs_getname(result); > > Another fundamental difference is how to treat the callback chains for > these two. > > Observers won't have a return value and are assumed to never fail, > therefore we can always call every entry on the callback list. > > Active things otoh do have a return value, and thus we need to have > semantics that define what to do with that during callback iteration, > when to continue and when to break. Thus for active elements its > impossible to guarantee all entries will indeed be called. 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. Even if the first one failed already we'd still want to trigger *all* the failures, because security policies like to know when they have triggered a failure (regardless of other active policies) and want to see that failure event (if they are logging such events). So to me this looks pretty similar to observer callbacks as well, it's the natural extension to an observer callback chain. Observer callbacks are simply constant functions (to the caller), those which never return failure and which never modify any of the parameters. It's as if you argued that there should be separate syscalls/facilities for handling readonly files versus handling read/write files. Thanks, Ingo From mboxrd@z Thu Jan 1 00:00:00 1970 From: mingo@elte.hu (Ingo Molnar) Date: Fri, 13 May 2011 14:54:52 +0200 Subject: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering In-Reply-To: <1305290612.2466.17.camel@twins> 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> Message-ID: <20110513125452.GD3924@elte.hu> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Peter Zijlstra wrote: > On Fri, 2011-05-13 at 14:39 +0200, Peter Zijlstra wrote: > > > > > event_vfs_getname(result); > > > result = check_event_vfs_getname(result); > > Another fundamental difference is how to treat the callback chains for > these two. > > Observers won't have a return value and are assumed to never fail, > therefore we can always call every entry on the callback list. > > Active things otoh do have a return value, and thus we need to have > semantics that define what to do with that during callback iteration, > when to continue and when to break. Thus for active elements its > impossible to guarantee all entries will indeed be called. 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. Even if the first one failed already we'd still want to trigger *all* the failures, because security policies like to know when they have triggered a failure (regardless of other active policies) and want to see that failure event (if they are logging such events). So to me this looks pretty similar to observer callbacks as well, it's the natural extension to an observer callback chain. Observer callbacks are simply constant functions (to the caller), those which never return failure and which never modify any of the parameters. It's as if you argued that there should be separate syscalls/facilities for handling readonly files versus handling read/write files. Thanks, Ingo