[PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
Ingo Molnar
mingo at elte.hu
Wed May 25 06:10:53 EST 2011
* Ingo Molnar <mingo at elte.hu> wrote:
>
> * Peter Zijlstra <peterz at infradead.org> wrote:
>
> > On Tue, 2011-05-24 at 10:59 -0500, Will Drewry wrote:
> > > include/linux/ftrace_event.h | 4 +-
> > > include/linux/perf_event.h | 10 +++++---
> > > kernel/perf_event.c | 49 +++++++++++++++++++++++++++++++++++++---
> > > kernel/seccomp.c | 8 ++++++
> > > kernel/trace/trace_syscalls.c | 27 +++++++++++++++++-----
> > > 5 files changed, 82 insertions(+), 16 deletions(-)
> >
> > I strongly oppose to the perf core being mixed with any sekurity voodoo
> > (or any other active role for that matter).
>
> I'd object to invisible side-effects as well, and vehemently so. But note how
> intelligently it's used here: it's explicit in the code, it's used explicitly
> in kernel/seccomp.c and the event generation place in
> kernel/trace/trace_syscalls.c.
>
> So this is a really flexible solution IMO and does not extend events with
> some invisible 'active' role. It extends the *call site* with an open-coded
> active role - which active role btw. already pre-existed.
Also see my other mail - i think this seccomp code is too tied in to the perf
core and ABI - but this is fixable IMO.
The fundamental notion that a generator subsystem of events can use filter
results as well (such as kernel/trace/trace_syscalls.c.) for its own purposes
is pretty robust though.
Thanks,
Ingo
More information about the Linuxppc-dev
mailing list