lkml.org 
[lkml]   [2020]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] ptrace: make ptrace() fail if the tracee changed its pid unexpectedly
From
Date
On 12/17/20 11:39 PM, Eric W. Biederman wrote:

>> resume the old leader L, it resumes the post-exec thread T which was
>> actually now stopped in PTHREAD_EVENT_EXEC. In this case the
>> PTHREAD_EVENT_EXEC event is lost, and the tracer can't know that the
>> tracee changed its pid.
>
> The change seems sensible. I don't expect this is common but it looks
> painful to deal with if it happens.

Yeah, the debug session becomes completely messed up, as the ptracer has no
idea the process is running a new image, breakpoints were wiped out, and
the post-exec process is resumed without the ptracer having had a chance
to install new breakpoints. I don't see any way to deal with it without
kernel help.

>
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> I am wondering if this should be expanded to all ptrace types for
> consistency. Or maybe we should set a flag to make this happen for
> all ptrace events.
>
> It just seems really odd to only worry about missing this event.
> I admit this a threaded PTRACE_EVENT_EXEC is the only event we are
> likely to miss but still.

It's more about the tid stealing than the event itself. I mean,
we lose the event because the tid changes magically without warning.
An exec is the only scenario where this happens.

>
> Do you by any chance have any debugger/strace test cases?
>
> I would think that would be the way to test to see if this breaks
> anything. I think I remember strace having a good test suite.

I ran the GDB testsuite against this, no regressions showed up.

BTW, the problem was discovered by Simon Marchi when he tried to write
a GDB testcase for a multi-threaded exec scenario:

https://sourceware.org/bugzilla/show_bug.cgi?id=26754

I've went through GDB's code looking for potential issues with the change and whether
it would affect GDBs already in the wild. Tricky corner cases abound, but I think
we're good. Feel free to add my ack:

Acked-by: Pedro Alves <palves@redhat.com>

Thanks,
Pedro Alves

\
 
 \ /
  Last update: 2020-12-19 17:21    [W:0.095 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site