From: Salman Qazi <sqazi@google.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: taviso@google.com, Roland Dreier <rolandd@cisco.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roland McGrath <roland@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: Race in ptrace.
Date: Wed, 10 Feb 2010 10:38:05 -0800 [thread overview]
Message-ID: <4352991a1002101038s6a2e67d9mc373416c17de9e6a@mail.gmail.com> (raw)
In-Reply-To: <20100210133556.GA21925@redhat.com>
[+tavis]
Sorry for the delayed response. I was out sick yesterday. I have
made a simpler version of tavis's test case:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <sched.h>
#include <errno.h>
#include <sys/ptrace.h>
#include <assert.h>
#include <sys/types.h>
#include <sys/wait.h>
int child_pid;
int ant_pid;
void child(void)
{
ptrace(PTRACE_TRACEME, 0, NULL, NULL);
asm("int3");
while(1);
}
void antagonist(void)
{
while (1) {
kill(child_pid, SIGSTOP);
usleep(2);
kill(child_pid, SIGCONT);
usleep(2);
}
}
int do_fork(void (*callback)(void))
{
int pid;
pid = fork();
if (pid)
return pid;
callback();
exit(EXIT_SUCCESS);
}
int main(int argc, char **argv)
{
int status;
assert((child_pid = do_fork(child)) > 0);
assert((ant_pid = do_fork(antagonist)) > 0);
waitpid(child_pid, &status, 0);
ptrace(PTRACE_SYSCALL, child_pid, NULL, NULL);
while(1) {
if (waitpid(child_pid, &status, 0) <= 0) {
printf("Errno %d\n", errno);
exit(EXIT_FAILURE);
}
if (WIFSTOPPED(status)) {
printf("stopped: %d\n", WSTOPSIG(status));
/* This should work, but sometimes it doesn't */
if (ptrace(PTRACE_SYSCALL, child_pid,
NULL, WSTOPSIG(status)) < 0) {
/* Oddly it works the second time! */
assert (ptrace(PTRACE_SYSCALL,
child_pid, NULL, WSTOPSIG(status)) < 0);
}
}
}
}
On Wed, Feb 10, 2010 at 5:35 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> On 02/09, Oleg Nesterov wrote:
>>
>> Salman Qazi wrote:
>> >
>> > A race in ptrace was pointed to us by a fellow Google engineer, Tavis
>> > Ormandy. The race involves interaction between a tracer, a tracee and
>> > an antagonist. The tracer is tracing the tracee with PTRACE_SYSCALL and
>> > waits on the tracee. In the mean time, an antagonist blasts the tracee
>> > with SIGCONTs.
>>
>> Could you please explain how did observe this race? Do you have a
>> test-case, or could you explain how we can reproduce it?
>>
>> Because,
>>
>> > It turns out that a SIGCONT wakes up the
>> > tracee in kernel mode,
>>
>> SIGCONT must not wake up a TASK_TRACED task.
>
> In case I wasn't clear...
>
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -697,6 +697,10 @@ static int prepare_signal(int sig, struct task_struct *p, int from_ancestor_ns)
> * and wake all threads.
> */
> rm_from_queue(SIG_KERNEL_STOP_MASK, &signal->shared_pending);
> + if (p->ptrace & PT_PTRACED) {
> + p->ptrace |= PT_WAKING;
> + mb();
> + }
>
> Please note that we are going to do wake_up_state(state), and
> this state can never have __TASK_TRACED bit set.
>
> And we can't change ->ptrace here, we can race with the tracer.
>
> There are other problems with this patch, but the main problem
> is that I can't understand what this patch tries to fix.
>
> IOW, please provide more info ;)
>
> Oleg.
>
>
next prev parent reply other threads:[~2010-02-10 18:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-08 22:16 Salman Qazi
[not found] ` <20100208143231.6d804590.akpm@linux-foundation.org>
2010-02-09 11:27 ` Oleg Nesterov
2010-02-10 13:35 ` Oleg Nesterov
2010-02-10 18:38 ` Salman Qazi [this message]
2010-02-11 12:56 ` Oleg Nesterov
2010-02-11 16:32 ` Salman Qazi
2010-02-11 16:50 ` Oleg Nesterov
2010-02-11 18:43 ` Salman Qazi
2010-02-11 18:55 ` Oleg Nesterov
2010-02-11 19:08 ` Salman Qazi
2010-02-11 20:10 ` Oleg Nesterov
2010-02-11 20:39 ` Salman Qazi
2010-02-11 20:55 ` Roland McGrath
2010-02-11 21:05 ` Salman Qazi
2010-02-11 20:59 ` Oleg Nesterov
-- strict thread matches above, loose matches on Subject: below --
2010-02-08 22:04 Salman Qazi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4352991a1002101038s6a2e67d9mc373416c17de9e6a@mail.gmail.com \
--to=sqazi@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=roland@redhat.com \
--cc=rolandd@cisco.com \
--cc=taviso@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®