Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757536AbbFCSgH (ORCPT ); Wed, 3 Jun 2015 14:36:07 -0400 Received: from mail-ie0-f169.google.com ([209.85.223.169]:35271 "EHLO mail-ie0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755356AbbFCSgD (ORCPT ); Wed, 3 Jun 2015 14:36:03 -0400 Date: Wed, 3 Jun 2015 12:36:00 -0600 From: Tycho Andersen To: Oleg Nesterov , Andy Lutomirski Cc: Andrey Wagin , LKML , linux-api@vger.kernel.org, Kees Cook , Will Drewry , Roland McGrath , Pavel Emelyanov , "Serge E. Hallyn" Subject: Re: [PATCH] seccomp: add ptrace commands for suspend/resume Message-ID: <20150603183600.GH3337@hopstrocity> References: <1433186918-9626-1-git-send-email-tycho.andersen@canonical.com> <20150602130506.GA1823@hopstrocity> <20150602184848.GA24907@redhat.com> <20150603161321.GD3337@hopstrocity> <20150603165451.GA20911@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150603165451.GA20911@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1735 Lines: 52 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/