linux-kernel - Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after PTRACE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=Djwcf9YoUrGtTEOp8W_YhsefzrNhMxVhtw_Lp@mail.gmail.com>
Date:	Mon, 14 Feb 2011 18:20:52 +0100
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Roland McGrath <roland@...hat.com>, jan.kratochvil@...hat.com,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after PTRACE_ATTACH

On Mon, Feb 14, 2011 at 4:13 PM, Tejun Heo <tj@...nel.org> wrote:
> Hello, Denys.
>
> On Sun, Feb 13, 2011 at 11:25:55PM +0100, Denys Vlasenko wrote:
>> But this "diddling behind group stop's back" is exactly the current
>> problem with stop signals.
>
> Maybe.  I don't necessarily agree but can see your point too but I
> think more important part is that that's a behavior which is quite
> noticeable from userland.
>
>> Here I try to stop a ptraced process:
>>
>> $ strace -tt sleep 30
>> 23:02:15.619262 execve("/bin/sleep", ["sleep", "30"], [/* 30 vars */]) = 0
>> ...
>> 23:02:15.622112 nanosleep({30, 0}, NULL) = ? ERESTART_RESTARTBLOCK (To be restarted)
>> 23:02:23.781165 --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
>> 23:02:23.781251 --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
>>     (I forgot again why we see it twice. Another quirk I guess...)
>> 23:02:23.781310 restart_syscall(<... resuming interrupted call ...>) = 0
>> 23:02:45.622433 close(1)                = 0
>> 23:02:45.622743 close(2)                = 0
>> 23:02:45.622885 exit_group(0)           = ?
>>
>> Why sleep didn't stop?
>>
>> Because PTRACE_SYSCALL brought the task out of group stop at once,
>> even though strace did try hard to not do so:
>>
>>     ptrace(PTRACE_SYSCALL, $PID, 0x1, SIGSTOP) <-- note SIGSTOP!
>>
>> PTRACE_CONT in this situation would do the same.
>
> This can be fixed by updating strace, right?  strace can look at the
> wait(2) exit code and if the tracee stopped for group stop, wait for
> the tracee to be continued instead of issuing PTRACE_SYSCALL.

But tracee didn't stop _yet_. Signal is not delivered _yet_, debugger
can decide at this point whether to deliver it:
ptrace(PTRACE_SYSCALL, $PID, 0x1, SIGSTOP)
or ignore:
ptrace(PTRACE_SYSCALL, $PID, 0x1, 0)

strace has to deliver SIGSTOP if it wants to make program run exactly
as it would run without strace. So it tries to do so.
Currently, ptrace machinery doesn't react as strace, its user, expects it to.

You are proposing to special-case SIGSTOP delivery in strace:
"if (sig != SIGSTOP) ptrace(PTRACE_SYSCALL, $PID, 0x1, sig)"

This is problematic. For example, will have an effect of not stopping
other threads of a multi-threaded process.


>> You are saying that it is useful that gdb restarts group-stopped task
>> with mere PTRACE_CONT. Above is a counter-example where it is anti-useful:
>> I would muchly prefer strace to see task sit stopped until it gets SIGCONT
>> (or some fatal signal).
>
> This is more of an issue which can be improved in strace.  Sure,
> changing the kernel to enforce group stop over ptrace would make this
> case behave better but at the cost of breaking gdb.
>
>> Why gdb can't use SIGCONT instead of PTRACE_CONT, just like every
>> other tool which needs to resume stopped tasks?
>
> Because that's how PTRACE_CONT behaved the whole time.  It can but
> just hasn't needed to.

Jan, please put on your gdb maintainer's hat, we need your opinion here.
Is it a problem from gdb's POV?

-- 
vda.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/