Messages in this thread | | | From | Denys Vlasenko <> | Date | Mon, 30 May 2011 16:27:37 +0200 | Subject | Re: execve-under-ptrace API bug (was Re: Ptrace documentation, draft #3) |
| |
On Mon, May 30, 2011 at 1:40 PM, Denys Vlasenko <vda.linux@googlemail.com> wrote: >>> I think the API needs fixing. Tracee must never disappear like that >>> on execve (or in any other case). They must always deliver a >>> WIFEXITED or WIFSIGNALED notification, allowing tracer to know >>> that they are gone. We probably also need to document how are these >>> "I died on execve" notifications are ordered wrt PTRACE_EVENT_EXEC >>> stop in execve-ing thread. >> >> A problem is that by the time de-threading is in progress, it's >> already too deep and there's no way back and the exec'ing thread has >> to wait for completion in uninterruptible sleeps - ie. it expects >> de-threading to finish in finite amount of time and to achieve that it >> basically sends SIGKILL to all other threads. > > Which is fine. Can we make the death from this "internal SIGKILL" > visible to the tracer of killed tracees?
Ok, let's take a deeper look at API needs. What we need to report, and when?
We have three kinds of threads at execve: 1. execve'ing thread, 2. leader, two cases: (2a) leader is still alive, (2b) leader has exited by now. 3. other threads.
(3) is the most simple: API should report death of these threads. There is no need to ensure these death notifications are reported before execve syscall exit is reported. They can be consumed by tracer later.
(1) execve'ing thread is obviously alive. current kernel already reports its execve success. The only thing we need to add is a way to retrieve its former pid, so that tracer can drop former pid's data, and also to cater for the "two execve's" case. PTRACE_EVENT_EXEC seems to be a good place to do it. Say, using GETEVENTMSG?
(2) is the most problematic. If leader is still alive, should we report its death? This makes sense since if we do, and if we ensure its death is always reported before PTRACE_EVENT_EXEC, then the rule is pretty simple: at PTRACE_EVENT_EXEC, leader is always reported dead.
However, I don't see why we _must_ do it this way. The life of tracer is not that much worse if at PTRACE_EVENT_EXEC leader which is still alive is simply "supplanted" by the execve'ed process.
We definitely must ensure, though, that if leader races with execve'ing thread and enters exit(2), its death is never reported *after* PTRACE_EVENT_EXEC - that'd confuse the tracer for sure! Process which has exited but is still alive?! Not good!
-- vda
| |