linux-mips
[Top] [All Lists]

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

To: Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar <mingo@elte.hu>
Date: Mon, 16 May 2011 14:00:43 +0200
Cc: Will Drewry <wad@chromium.org>, 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>, "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: <201105150842.07816.arnd@arndb.de>
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> <201105150842.07816.arnd@arndb.de>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.20 (2009-08-17)
* Arnd Bergmann <arnd@arndb.de> wrote:

> 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.

One thing we could do more clearly here is to help keep the filter expressions 
symbolic - i.e. help resolve the various ioctl variants as well, not just the 
raw syscall parameter numbers.

But yes, access to the raw syscall parameters and the ability to filter them 
already gives us the ability to exclude/include specific ioctls in a rather 
flexible way.

Thanks,

        Ingo

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