Messages in this thread | | | Date | Wed, 1 Jun 2011 09:00:23 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH v3 02/13] tracing: split out syscall_trace_enter construction |
| |
* Will Drewry <wad@chromium.org> wrote:
> perf appears to be the primary consumer of the CONFIG_FTRACE_SYSCALLS > infrastructure. As such, many the helpers target at perf can be split > into a peerf-focused helper and a generic CONFIG_FTRACE_SYSCALLS > consumer interface. > > This change splits out syscall_trace_enter construction from > perf_syscall_enter for current into two helpers: > - ftrace_syscall_enter_state > - ftrace_syscall_enter_state_size > > And adds another helper for completeness: > - ftrace_syscall_exit_state_size > > These helpers allow for shared code between perf ftrace events and > any other consumers of CONFIG_FTRACE_SYSCALLS events. The proposed > seccomp_filter patches use this code. > > Signed-off-by: Will Drewry <wad@chromium.org> > --- > include/trace/syscall.h | 4 ++ > kernel/trace/trace_syscalls.c | 96 +++++++++++++++++++++++++++++++++++------ > 2 files changed, 86 insertions(+), 14 deletions(-)
So, looking at the diffstat comparison again:
bitmask (2009): 6 files changed, 194 insertions(+), 22 deletions(-) filter engine (2010): 18 files changed, 1100 insertions(+), 21 deletions(-) event filters (2011): 5 files changed, 82 insertions(+), 16 deletions(-)
you went back to the middle solution again which is the worst of them - why?
If you want this to be a stupid, limited hack then go for the v1 bitmask.
If you agree with my observation that filters allow the clean user-space implementation of LSM equivalent security solutions (of which sandboxes are just a *narrow special case*) then please use the main highlevel abstraction we have defined around them: event filters.
Now, my observation was not uncontested so let me try to sum up the rather large discussion that erupted around it, as i see it.
I saw four main counter arguments:
- "Sandboxing is special and should stay separate from LSMs."
I think this is a technically bogus argument, see:
https://lkml.org/lkml/2011/5/26/85
That answer of mine went unchallenged.
- "Events should only be observers."
Even ignoring the question of why on earth it should be a problem for a willing call-site to use event filtering results sensibly, this argument misses the plain fact that events are *already* active participants, see:
http://www.spinics.net/lists/mips/msg41075.html
That answer of mine went unchallenged too.
- "This feature is too simplistic."
That's wrong i think, the feature is highly flexible:
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg51387.html
This reply of mine went unchallenged as well.
- "Is this feature actually useful enough for applications, does it justify the complexity?"
This is the *only* valid technical counter-argument i saw, and it's a crutial one that is not fully answered yet. Since i think the feature is an LSM equivalent i think it's at least as useful as any LSM is.
- [ if i missed any important argument then someone please insert it here. ]
But what you do here is to use the filter engine directly which is both a limited hack *and* complex (beyond the linecount it doubles our ABI exposure, amongst other things), so i find that approach rather counter-productive, now that i've seen the real thing.
Will this feature be just another example of the LSM status quo dragging down a newcomer into the mud, until it's just as sucky and limited as any existing LSMs? That would be a sad outcome!
Thanks,
Ingo
ps. Please start a new discussion thread for the next iteration! This one is *way* too deep already.
| |