Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1157810 > unrolled thread

Re: [PATCH] seccomp: add ptrace commands for suspend/resume

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] seccomp: add ptrace commands for suspend/resume Tycho Andersen <tycho.andersen@canonical.com> - 2015-06-03 18:20 +0200
    Re: [PATCH] seccomp: add ptrace commands for suspend/resume Tycho Andersen <tycho.andersen@canonical.com> - 2015-06-03 19:00 +0200
    Re: [PATCH] seccomp: add ptrace commands for suspend/resume Oleg Nesterov <oleg@redhat.com> - 2015-06-03 19:00 +0200

#1157810 — Re: [PATCH] seccomp: add ptrace commands for suspend/resume

On Tue, Jun 02, 2015 at 08:48:48PM +0200, Oleg Nesterov wrote:
> On 06/02, Tycho Andersen wrote:
> >
> > > Do we need to re-enable seccomp if a tracer detaches unexpectedly.
> > > CRIU can be killed and we should try to not affect the task state even
> > > in this case.
> >
> > Yes, I think Pavel's suggestion on the CRIU list of simply
> > automatically re-enabling seccomp on ptrace detach
> 
> But note that you can't enable tsc if the tracer dies, in this case
> the tracee can be running.

Yes, this does complicate things. I think I'll get rid of the TSC
manipulation, since it's not clear to me how to resolve this. (I do
think it makes the API slightly incomplete, though, so suggestions how
to resolve it would be welcome.)

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

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/

[toc] | [next] | [standalone]

#1157848

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?

I see, I misunderstood. Yes, this is a lot nicer, thank you.

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/

[toc] | [prev] | [next] | [standalone]

#1157850

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?

Oleg.

--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web