Messages in this thread | | | Date | Wed, 3 Jun 2015 12:36:00 -0600 | From | Tycho Andersen <> | Subject | Re: [PATCH] seccomp: add ptrace commands for suspend/resume |
| |
On Wed, Jun 03, 2015 at 06:54:51PM +0200, Oleg Nesterov wrote: > On 06/03, Tycho Andersen wrote: > > > > On Tue, Jun 02, 2015 at 08:48:48PM +0200, Oleg Nesterov wrote: > > > > > Otherwise, if we use PTRACE_O_ instead, it goes away automatically if > > > the tracer dies or does PTRACE_DETACH. > > > > IIRC the flag goes away, but we still have to do something in > > __ptrace_unlink to clear the seccomp suspended, so I'm not sure if the > > automatic-ness helps us. > > But we do not need seccomp->suspended at all? > > Unless I missed something PTRACE_O_ needs a one-liner patch (ignoring > the defines in include files), > > --- x/kernel/seccomp.c > +++ x/kernel/seccomp.c > @@ -692,6 +692,9 @@ u32 seccomp_phase1(struct seccomp_data * > int this_syscall = sd ? sd->nr : > syscall_get_nr(current, task_pt_regs(current)); > > + if (unlikely(current->ptrace & PT_NAME_OF_THIS_OPTION)) > + return OK; > + > switch (mode) { > case SECCOMP_MODE_STRICT: > __secure_computing_strict(this_syscall); /* may call do_exit */ > > > OK, and the same check in secure_computing_strict(). > > No?
One problem with this is that we still incur the runtime overhead of checking, which I guess is a question of ptrace vs. seccomp complexity.
Andy had suggested multiplexing seccomp->suspended into seccomp->mode directly to avoid this, but the above still requires a check. We could play with TIF_SECCOMP, but that has the same problems as playing with TIF_NOTSC.
Thoughts?
Tycho
| |