PTRACE_KILL doesn't (2.5.44 and others)

PTRACE_KILL doesn't (2.5.44 and others)

[Werner Almesberger]

If the process being ptraced is running, PTRACE_KILL will have no
effect. I've seen this in 2.5.44, and the code in 2.4.18 and 2.5.66
seems to be equivalent.

According to the ptrace(2) man page (as of man-pages-1.56),
PTRACE_KILL doesn't require the process to be stopped for this to
work.

Who is right ?

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

Re: PTRACE_KILL doesn't (2.5.44 and others)

[Andries Brouwer]

On Sun, Mar 30, 2003 at 08:51:26PM -0300, Werner Almesberger wrote:

> If the process being ptraced is running, PTRACE_KILL will have no
> effect. I've seen this in 2.5.44, and the code in 2.4.18 and 2.5.66
> seems to be equivalent.
> 
> According to the ptrace(2) man page (as of man-pages-1.56),
> PTRACE_KILL doesn't require the process to be stopped for this to
> work.
> 
> Who is right ?

First of all, it is dangerous to depend on subtle properties
of obscure calls like ptrace. Only the part that is common to
all Unix implementations of ptrace is somewhat reliable.

A random non-Linux man page says

-----
     The ptrace() function allows a parent process to control the
     execution  of  a  child  process. Its primary use is for the
     implementation of breakpoint debugging.  The  child  process
     behaves   normally   until   it  encounters  a  signal  (see
     signal(3HEAD)), at which time it enters a stopped state  and
     its  parent  is  notified via the wait(2) function. When the
     child is in the stopped state, its parent  can  examine  and
     modify its "core image" using ptrace(). Also, the parent can
     cause the child either to terminate or  continue,  with  the
     possibility of ignoring the signal that caused it to stop.
...
     8     This request causes the child to  terminate  with  the
           same consequences as exit(2).
-----

so, this suggests that ptrace only does something when the child
is stopped.

The Linux man page says

-----
       While being traced, the child will stop each time a signal
       is  delivered,  even if the signal is being ignored.  (The
       exception is SIGKILL, which has its  usual  effect.)   The
       parent  will  be  notified  at  its  next  wait(2) and may
       inspect and modify the child process while it is  stopped.
       The  parent  then causes the child to continue, optionally
       ignoring the delivered signal (or even delivering  a  dif-
       ferent signal instead).

       When  the parent is finished tracing, it can terminate the
       child with PTRACE_KILL or cause it to  continue  executing
       in a normal, untraced mode via PTRACE_DETACH.
-----

Here is is not completely clear whether the start of a new paragraph
means that PTRACE_KILL functions also when the child is not stopped.

For Linux, inspection of the kernel source suggests that the intention
of the author was to make PTRACE_KILL work also when the child is not
stopped, but indeed, as you say, it doesnt work that way.

Since it is not clear what the right behaviour is, it is not clear
whether there is something to fix. Maybe the man page could use an
additional sentence, or removal of whitespace.

Andries

Re: PTRACE_KILL doesn't (2.5.44 and others)

[Werner Almesberger]

Andries Brouwer wrote:
> First of all, it is dangerous to depend on subtle properties
> of obscure calls like ptrace.

Indeed ;-) Well, there are worse things, e.g. DWARF2
information versus optimization.

> The Linux man page says

It also says (man-pages-1.56):

| For requests other than  PTRACE_KILL,  the  child  process
| must be stopped.

Of course, it doesn't explicitly say that PTRACE_KILL will do
anything in this case, but the wording kind of suggests that.

> Since it is not clear what the right behaviour is, it is not clear
> whether there is something to fix.

Yes, that's my question. If we're trying to emulate the exact
behaviour of some other OS or some specification, that would
give the answer. If not, we can decide what makes sense, and,
if a change would be needed for the semantics to make sense,
whether it's worth making that change.

At least it seems that existing code is fine with how
PTRACE_KILL works, given how long it has behaved like that.
(But then, existing code may rarely use PTRACE_KILL, and may
not be particularly picky about the result.)

What puzzles me a little is that kill(2) seems to do precisely
what I would have expected PTRACE_KILL to do, i.e. kill the
process no matter whether it's stopped or not, and detach from
it. So why is there a PTRACE_KILL in the first place ?

The non-Linux man page you quote says:

|    8     This request causes the child to  terminate  with  the
|          same consequences as exit(2).

Then it would make sense. Of course, this isn't what
PTRACE_KILL does under Linux. Does that non-Linux man page
also say anything about the exit status ?

Another subtlety, seen under 2.5.44: if PTRACE_ATTACH is
immediately followed by PTRACE_KILL, PTRACE_KILL is silently
ignored (no error).

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/