ptrace() behaviour when doing PTRACE_KILL

ptrace() behaviour when doing PTRACE_KILL

[Pablo Antonio]

Hello,
    I was writing some user code that uses the ptrace() system call
and found it wasn't behaving as I expected. Maybe this is simply
because I don't know enough about ptrace()'s behaviour, so I'd like
someone to enlighten me with some information.

So, here's the code: http://codepad.org/TJ7Lua4Q Basically, I was
expecting the parent process to kill the child when the later
attempted to use the kill() system call, not letting it send signals
to other processes. I had done this before with pretty much the same
code, but instead of killing when kill() was called, I was doing it
when a fork() or clone() was attempted. And it worked. If the child
process tried to create a new process via fork() or clone(), then it
was immediately killed and no process was created.

But now that I'm doing the same thing with kill(), I'm seeing that the
child process ends up killed, as expected, but the signal is sent
nonetheless. I understand that when I do the PTRACE_KILL, a SIGKILL
signal is sent to the child. And PTRACE_KILL is used on syscall
entrance in that code. If the SIGKILL signal is delivered to the
process before it continues executing the system call in kernelspace,
then I don't understand why this code doesn't work as expected. If the
signal is delivered after the system call is completely executed, then
I don't understand why this was working for the fork() and clone()
case.

I'd really appreciate if someone told me what's happening here, or
what I'm not seeing.

Thanks,

-- 
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

ptrace() behaviour when doing PTRACE_KILL

[Pablo Antonio]

Hello,
? ?I was writing some user code that uses the ptrace() system call
and found it wasn't behaving as I expected. Maybe this is simply
because I don't know enough about ptrace()'s behaviour, so I'd like
someone to enlighten me with some information.

So, here's the code: http://codepad.org/TJ7Lua4Q Basically, I was
expecting the parent process to kill the child when the later
attempted to use the kill() system call, not letting it send signals
to other processes. I had done this before with pretty much the same
code, but instead of killing when kill() was called, I was doing it
when a fork() or clone() was attempted. And it worked. If the child
process tried to create a new process via fork() or clone(), then it
was immediately killed and no process was created.

But now that I'm doing the same thing with kill(), I'm seeing that the
child process ends up killed, as expected, but the signal is sent
nonetheless. I understand that when I do the PTRACE_KILL, a SIGKILL
signal is sent to the child. And PTRACE_KILL is used on syscall
entrance in that code. If the SIGKILL signal is delivered to the
process before it continues executing the system call in kernelspace,
then I don't understand why this code doesn't work as expected. If the
signal is delivered after the system call is completely executed, then
I don't understand why this was working for the fork() and clone()
case.

I'd really appreciate if someone told me what's happening here, or
what I'm not seeing.

Thanks,

--
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/

ptrace() behaviour when doing PTRACE_KILL

[Mulyadi Santosa]

Hi pablo....

On Mon, Aug 29, 2011 at 14:47, Pablo Antonio <pabloa@gmail.com> wrote:
 If the
> signal is delivered after the system call is completely executed, then
> I don't understand why this was working for the fork() and clone()
> case.
>
> I'd really appreciate if someone told me what's happening here, or
> what I'm not seeing.

I don't really get your question perfectly, but I guess you're
questioning about why kill() gets different result than fork()/clone
in term of order?

I guess that is the result of fork policy. Child, in Linux, AFAIK is
executed after parent. This is controlled via
/proc/sys/kernel/sched_child_runs_first. The effect is that, as you
can imagine, that parent take control first on anything over child. If
you change it, then child has a chance to do something ahead.

Again,  I don't claim I know your question perfectly, so as usual CMIIW.


-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

ptrace() behaviour when doing PTRACE_KILL

[Pablo Antonio]

Hi Oleg,

On Tue, Aug 30, 2011 at 10:30 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> Pablo Antonio wrote:
>>
>> Hello,
>> ? ?I was writing some user code that uses the ptrace() system call
>> and found it wasn't behaving as I expected. Maybe this is simply
>> because I don't know enough about ptrace()'s behaviour, so I'd like
>> someone to enlighten me with some information.
>
> First of all, please never use PTRACE_KILL. it is more or less
> equivalent to ptrace(PTRACE_CONT, pid, 0, SIGKILL) but doesn't return
> the error.
>
>> So, here's the code: http://codepad.org/TJ7Lua4Q Basically,
>
> I assume you run it on 32bit machine... otherwise you need
> "8 * ORIG_RAX" and "8 * RAX".

Yes, x86-32.

>
>> I was
>> expecting the parent process to kill the child when the later
>> attempted to use the kill() system call, not letting it send signals
>> to other processes. I had done this before with pretty much the same
>> code, but instead of killing when kill() was called, I was doing it
>> when a fork() or clone() was attempted. And it worked.
>
> Because do_fork() checks signal_pending() and aborts if the process
> is killed (actually it aborts if any signal is pending).
>
>> But now that I'm doing the same thing with kill(), I'm seeing that the
>> child process ends up killed, as expected, but the signal is sent
>> nonetheless. I understand that when I do the PTRACE_KILL, a SIGKILL
>> signal is sent to the child. And PTRACE_KILL is used on syscall
>> entrance in that code. If the SIGKILL signal is delivered to the
>> process before it continues executing the system call in kernelspace,
>
> In this particular case SIGKILL was already delivered, yes.
>
>> then I don't understand why this code doesn't work as expected.
>
> Because you didn't abort this syscall. The tracee calls sys_kill()
> which doesn't check the signals, the pending SIGKILL will be noticed
> later, when the tracee attampts to return to the user-mode.
>
> This is correct. Most of non-blocking syscalls do not check the
> signals, this is pointless.

Thanks for your answer, Oleg. What you are saying makes sense to me,
but I must say that I talked with some people (one of them was a GDB
developer, the other was Denys Vlasenko) and they tested the code I
you saw with different kernels and the signal was inhibited. Both of
them, I think, were using redhat/fedora kernels.

Maybe there's a race condition happening, maybe redhat/fedora kernels
have different behaviour, I don't know. But I guess that if there's a
difference in behaviour between vanilla and fedora/redhat kernels,
that should be fixed.

Thanks for your time,

-- 
Pablo Antonio (AKA crazy2k)
http://www.pablo-a.com.ar/