linux-mips
[Top] [All Lists]

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filt

To: Will Drewry <wad@chromium.org>
Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Arnd Bergmann <arnd@arndb.de>
Date: Sun, 15 May 2011 08:42:07 +0200
Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, linux-sh@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>, Frederic Weisbecker <fweisbec@gmail.com>, Heiko Carstens <heiko.carstens@de.ibm.com>, David Howells <dhowells@redhat.com>, Paul Mackerras <paulus@samba.org>, Eric Paris <eparis@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, sparclinux@vger.kernel.org, Jiri Slaby <jslaby@suse.cz>, linux-s390@vger.kernel.org, Russell King <linux@arm.linux.org.uk>, x86@kernel.org, jmorris@namei.org, Ingo Molnar <mingo@redhat.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Ingo Molnar <mingo@elte.hu>, "Serge E. Hallyn" <serge@hallyn.com>, Peter Zijlstra <a.p.zijlstra@chello.nl>, microblaze-uclinux@itee.uq.edu.au, Steven Rostedt <rostedt@goodmis.org>, Martin Schwidefsky <schwidefsky@de.ibm.com>, Thomas Gleixner <tglx@linutronix.de>, kees.cook@canonical.com, Roland McGrath <roland@redhat.com>, Michal Marek <mmarek@suse.cz>, Michal Simek <monstr@monstr.eu>, linuxppc-dev@lists.ozlabs.org, Oleg Nesterov <oleg@redhat.com>, Ralf Baechle <ralf@linux-mips.org>, Paul Mundt <lethal@linux-sh.org>, Tejun Heo <tj@kernel.org>, linux390@de.ibm.com, Andrew Morton <akpm@linux-foundation.org>, agl@chromium.org, "David S. Miller" <davem@davemloft.net>
In-reply-to: <BANLkTinukLesDoXzXKdtdRwgHtJkthXK0A@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1304017638.18763.205.camel@gandalf.stny.rr.com> <201105132135.34741.arnd@arndb.de> <BANLkTinukLesDoXzXKdtdRwgHtJkthXK0A@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: KMail/1.12.2 (Linux/2.6.37; KDE/4.3.2; x86_64; ; )
On Saturday 14 May 2011, Will Drewry wrote:
> Depending on integration, it could even be limited to ioctl commands
> that are appropriate to a known fd if the fd is opened prior to
> entering seccomp mode 2. Alternatively, __NR__ioctl could be allowed
> with a filter of "1" then narrowed through a later addition of
> something like "(fd == %u && (cmd == %u || cmd == %u))" or something
> along those lines.
> 
> Does that make sense?

Thanks for the explanation. This sounds like it's already doing all
we need.

        Arnd

<Prev in Thread] Current Thread [Next in Thread>