Messages in this thread | | | From | (Eric W. Biederman) | Date | Thu, 09 Apr 2020 15:34:26 -0500 | Subject | Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1 |
| |
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, Apr 9, 2020 at 10:06 AM Eric W. Biederman <ebiederm@xmission.com> wrote: >> >> a) We must stop in PTRACE_EVENT_EXIT during exec or userspace *breaks*. >> >> Those are the defined semantics and I believe it is something >> as common as strace that depends on them. > > Don't be silly. > > Of course we must stop IF THE TRACER IS ACTUALLY TRACING US. > > But that's simply not the case. The deadlock case is where the tracer > is going through an execve, and the tracing thread is being killed.
Linus please don't be daft.
I will agree that if one thread in a process ptracess another thread in the same process, and the tracing thread calls execve we have a problem. A different problem but one worth addressing.
The deadlock case I am talking about. The deadlock case that trivially exists in real code is:
A single threaded process (the tracer) ptrace attaches to every thread of a multi-threaded process (the tracee).
If one of these attaches succeeds, and another thread of the tracee processes calls execve before the tracer attachs to it, then the tracer blocks in ptrace_attach waitiing for the traccee's exeve to succeed while the tracee blocks in de_thread waiting for it's other threads to exit. The threads of the tracee attempt to exit but one or more of them are in PTRACE_EVENT_EXIT waiting for the tracer to let them continue.
The tracer of course is stalled waiting for the exec to succeed.
Let me see if I can draw a picture.
Tracer TraceeThreadA TraceeThreadB ptrace_attach(TraceeThreadA) execve acquires cred_guard_mutex ptrace_attach(TraceeThreadB) Blocks on cred_guard_mutex de_thread waits for other threads to exit Receives SIGKILL do_exit() PTRACE_EVENT_EXIT Waits for tracer
So we have a loop.
TraceeThreadB is waiting for TraceeThreadA to reach exit_noitfy. TraceeThreadA is waiting for the tracer to allow it to continue. The Tracer is waiting for TraceeThreadB to finish it's call to exec.
Since they are all waiting for each other that loop is a deadlock.
All it takes is a tracer that uses PTRACE_EVENT_EXIT.
Does that make the deadlock that I see clear?
In your proposed lock revision you were talking about ptrace_attach taking your new the lock for write so I don't see your proposed lock being any different in this scenario from cred_guard_mutex. Perhaps I missed something?
I know Oleg's test case was a little more involved but that was to guarantee the timing perhaps that introduced confusion.
Eric
| |