From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 13 May 2011 17:27:46 +0200 (CEST) Received: from bombadil.infradead.org ([18.85.46.34]:38078 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1491839Ab1EMP1j convert rfc822-to-8bit (ORCPT ); Fri, 13 May 2011 17:27:39 +0200 Received: from canuck.infradead.org ([134.117.69.58]) by bombadil.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1QKuH0-0001mR-Sp; Fri, 13 May 2011 15:27:26 +0000 Received: from j77219.upc-j.chello.nl ([24.132.77.219] helo=twins) by canuck.infradead.org with esmtpsa (Exim 4.72 #1 (Red Hat Linux)) id 1QKuGz-0003bN-Pn; Fri, 13 May 2011 15:27:26 +0000 Received: by twins (Postfix, from userid 1000) id D1BAD8130A54; Fri, 13 May 2011 17:27:23 +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 , 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: <20110513145737.GC32688@elte.hu> References: <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> <1305294935.2466.64.camel@twins> <20110513145737.GC32688@elte.hu> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Fri, 13 May 2011 17:27:23 +0200 Message-ID: <1305300443.2466.77.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: 29997 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 16:57 +0200, Ingo Molnar wrote: > this is a security mechanism Who says? and why would you want to unify two separate concepts only to them limit it to security that just doesn't make sense. Either you provide a full on replacement for notifier chain like things or you don't, only extending trace events in this fashion for security is like way weird. Plus see the arguments Eric made about stacking stuff, not only security schemes will have those problems. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 9382CB6F08 for ; Sat, 14 May 2011 01:27:45 +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: <20110513145737.GC32688@elte.hu> References: <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> <1305294935.2466.64.camel@twins> <20110513145737.GC32688@elte.hu> Content-Type: text/plain; charset="UTF-8" Date: Fri, 13 May 2011 17:27:23 +0200 Message-ID: <1305300443.2466.77.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 , kees.cook@canonical.com, "Serge E. Hallyn" , Steven Rostedt , Tejun Heo , Thomas Gleixner , linux-arm-kernel , Michal Marek , Michal Simek , Will Drewry , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Ralf Baechle , Paul Mundt , Martin Schwidefsky , 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 16:57 +0200, Ingo Molnar wrote: > this is a security mechanism Who says? and why would you want to unify two separate concepts only to them limit it to security that just doesn't make sense. Either you provide a full on replacement for notifier chain like things or you don't, only extending trace events in this fashion for security is like way weird. Plus see the arguments Eric made about stacking stuff, not only security schemes will have those problems. From mboxrd@z Thu Jan 1 00:00:00 1970 From: peterz@infradead.org (Peter Zijlstra) Date: Fri, 13 May 2011 17:27:23 +0200 Subject: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering In-Reply-To: <20110513145737.GC32688@elte.hu> References: <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> <1305294935.2466.64.camel@twins> <20110513145737.GC32688@elte.hu> Message-ID: <1305300443.2466.77.camel@twins> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, 2011-05-13 at 16:57 +0200, Ingo Molnar wrote: > this is a security mechanism Who says? and why would you want to unify two separate concepts only to them limit it to security that just doesn't make sense. Either you provide a full on replacement for notifier chain like things or you don't, only extending trace events in this fashion for security is like way weird. Plus see the arguments Eric made about stacking stuff, not only security schemes will have those problems.