* Thomas Gleixner <[email protected]> wrote:
> > > We do _NOT_ make any decision based on the trace point so
> > > what's the "pre-existing" active role in the syscall entry
> > > code?
> >
> > The seccomp code we are discussing in this thread.
>
> That's proposed code and has absolutely nothing to do with the
> existing trace point semantics.
So because it's proposed code it does not exist?
If the feature is accepted (and given Linus's opinion it's not clear
at all it's accepted in any form) then it's obviously a very
legitimate technical concern whether we do:
ret = seccomp_check_syscall_event(p1, p2, p3, p4, p5);
if (ret)
return -EACCES;
... random code ...
trace_syscall_event(p1, p2, p3, p4, p5);
Where seccomp_check_syscall_event() duplicates much of the machinery
that is behind trace_syscall_event().
Or we do the more intelligent:
ret = check_syscall_event(p1, p2, p3, p4, p5);
if (ret)
return -EACCES;
Where we have the happy side effects of:
- less code at the call site
- (a lot of!) shared infrastructure between the proposed seccomp
code and event filters.
- we'd also be able to trace at security check boundaries - which
has obvious bug analysis advantages.
In fact i do not see *any* advantages in keeping this needlessly
bloaty and needlessly inconsistently sampled form of instrumentation:
ret = seccomp_check_syscall_event(p1, p2, p3, p4, p5);
if (ret)
return -EACCES;
... random code ...
trace_syscall_event(p1, p2, p3, p4, p5);
Do you?
Thanks,
Ingo
_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://lists.ozlabs.org/listinfo/linuxppc-dev
