linux-kernel - Re: RFC: PTRACE_SEIZE needs API cleanup?

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 7 Sep 2011 04:47:45 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	"Indan Zupancic" <indan@....nu>
Cc:	"Denys Vlasenko" <dvlasenk@...hat.com>,
	"Oleg Nesterov" <oleg@...hat.com>, "Tejun Heo" <tj@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: RFC: PTRACE_SEIZE needs API cleanup?

On Tuesday 06 September 2011 19:19, Indan Zupancic wrote:
> >> > In case you meant that "if we request group-stop notifications by using
> >> > __WALL | WSTOPPED, and we get group-stop notification, and we do
> >> > PTRACE_CONT, then task does not run (it sits in group-stop until SIGCONT
> >> > or death)", then we have a problem: gdb can't use this interface, it
> >> > needs to be able to restart the thread (only one thread, not all of
> >> > them, so sending SIGCONT is not ok!) from the group-stop. Yes, it's
> >> > weird, but it's the real requirement from gdb users.
> >> [...]
> >> > SIGCONT's side effect of waking up from group-stop can't be blocked.
> >> > SIGCONT always wakes up all threads in thread group.
> >> > Using SIGCONT to control tracee will race with SIGCONTs from other
> >> > sources.
> >> >
> >> > This makes SIGCONT a too coarse instrument for the job.
> >> [...]
> >> > Yes... until gdb will want to give user a choice after SIGSTOP: continue
> >> > to sit in group-stop until SIGCONT (wasn't possible until
> >> > PTRACE_LISTEN), or continue executing (gdb's current behavior if user
> >> > uses "continue" command). Therefore, gdb needs a way to do both.
> >>
> >> Having thought a bit more about this, I think this is less of a problem
> >> than it seems, because for a group stop we get a ptrace event for each
> >> task, and this should be true for SIGCONT as well. So gdb could also
> >> always let the group stop happen, and only when prompted to do so by
> >> a user, continue one thread by sending SIGCONT and letting all the other
> >> threads hang in trapped state.
> >
> > Won't work. SIGCONT unpauses all threads in the thread group,
> > and _then_ it is delivered to one of the threads.
> 
> No, it is delivered to _all_ threads.

Wrong.

> With current ptrace you never see a SIGCONT

Wrong. Even rather old strace 4.5.9 does show it.



#include <stdlib.h>
#include <pthread.h>
static void *threadfunc(void *p)
{
        sleep(10);
        exit(0);
}
int main()
{
        printf("%d\n", getpid());
        pthread_t thread;
        pthread_create(&thread, NULL, threadfunc, NULL);
        sleep(10);
        exit(0);
}


$ gcc -Os -lpthread t.c -ot
$ strace -V
strace -- version 4.5.9
$ strace -oLOG -s999 -tt -f ./t
umovestr: Input/output error
9590
umovestr: Input/output error
ptrace: umoven: Input/output error

In other terminal: "kill -CONT 9590"

LOG:

9590  04:41:13.984640 clone(...) = 9591
9590  04:41:13.984712 rt_sigprocmask(SIG_BLOCK, [CHLD],  <unfinished ...>
...
9591  04:41:13.984972 <... rt_sigaction resumed> {SIG_DFL}, 8) = 0
9590  04:41:13.984993 nanosleep({10, 0},  <unfinished ...>
9591  04:41:13.985015 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
9591  04:41:13.985056 nanosleep({10, 0},  <unfinished ...>
9590  04:41:19.969687 <... nanosleep resumed> 0xff9e6fa4) = ? ERESTART_RESTARTBLOCK (To be restarted)
9590  04:41:19.969762 --- SIGCONT (Continued) @ 0 (0) ---
9590  04:41:19.969791 setup()           = 0
9591  04:41:23.985155 <... nanosleep resumed> {10, 0}) = 0
9590  04:41:23.985201 exit_group(0)     = ?
9591  04:41:23.985231 exit_group(0)     = ?


Take a good look. There was no SIGCONT delivery to thread 9591.


> > You can block
> > or ignore it, yes, but it is too late: the unpausing already happened,
> > and blocking/ignoring will only affect SIGCONT handler execution,
> > if the program has one.
> 
> Not doing PTRACE_CONT will keep the thread hanging in trapped state.
> All threads get a SIGCONT, not only one, so you can pause all threads
> this way.

As I said, you are wrong about SIGCONT.

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