[lkml]   [2011]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v3 02/13] tracing: split out syscall_trace_enter construction

    * Will Drewry <> 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 <>
    > ---
    > 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

    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

    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:

    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:

    That answer of mine went unchallenged too.

    - "This feature is too simplistic."

    That's wrong i think, the feature is highly flexible:

    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!



    ps. Please start a new discussion thread for the next iteration!
    This one is *way* too deep already.

     \ /
      Last update: 2011-06-01 09:03    [W:0.025 / U:6.400 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site