Messages in this thread | | | Subject | Re: [RFC PATCH] ptrace: make ptrace() fail if the tracee changed its pid unexpectedly | From | Pedro Alves <> | Date | Sat, 19 Dec 2020 16:19:31 +0000 |
| |
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
| |