linux-kernel - Re: ptrace && task->exit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090529190627.GA7017@redhat.com>
Date:	Fri, 29 May 2009 21:06:27 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Roland McGrath <roland@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, jan.kratochvil@...hat.com,
	Denys Vlasenko <dvlasenk@...hat.com>
Subject: Re: ptrace && task->exit_code

On 05/27, Roland McGrath wrote:
>
> > I didn't realize this until yesterday, but perhaps it makes sense
> > to decouple ptrace && task_struct->exit_code?
>
> I've long thought this was an attractive idea.  But it seems to have lots
> of complications at least as long as ptrace-wait shares so much code with
> normal wait.  I'd figured this might be one of the last things we clean up
> after ptrace is disentangled from core data structures in most every other
> way.
>
> > This is not completely trivial, needs another short series.
>
> I suspect it is more hassle than benefit to do this now.
> I don't think it is the right priority.
>
> > And. I spent a lot of time, but I can't see how to solve the problems
> > with TASK_STOPPED tasks if we do this change.
>
> I bet the complications of this all will be substantially different after
> we change the ptrace locking.  So let's not worry about it yet.

I just can't stop thinking of it ;)

Perhaps I missed something, but except the problem above this does not
look too hard. How about something like this:

	--- a/kernel/ptrace.c
	+++ b/kernel/ptrace.c
	@@ -228,7 +228,11 @@ int ptrace_attach(struct task_struct *task)
	 
		__ptrace_link(task, current);
	 
	-	send_sig_info(SIGSTOP, SEND_SIG_FORCED, task);
	+	spin_lock(task->signal->siglock);
	+	if (task_is_stopped(task) && !task->exit_code)
	+		task->exit_code = SIGSTOP;
	+	specific_send_sig_info(SIGSTOP, SEND_SIG_FORCED, task);
	+	spin_unlock(task->signal->siglock);
	 bad:
		write_unlock_irqrestore(&tasklist_lock, flags);
		task_unlock(task);

?

If we attach, and the task is already stopped, this really means
it was traced and untraced. We can set ->exit_code = SIGSTOP to
ensure do_wait() will succeed.

This also relates to attach-wait-on-stopped test-case, I cc'ed
Jan and Denys.

Note also that after

	do_wait: fix waiting for the group stop with the dead leader
	commit: 90bc8d8b1a38f1ab131a2399a202e1889db95de8

we can't confuse task->real_parent waiting for jctl stop.

What do you think?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/