Re: [PATCH v3 02/13] tracing: split out syscall_trace_enter construction

[Ingo Molnar <mingo@elte.hu>]

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