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: <AANLkTikYf1CE41x6FjE6FiZ40v8taRSy8aZ3-5tjAvok@mail.gmail.com>
Date:	Mon, 14 Feb 2011 18:24:58 +0100
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Tejun Heo <tj@...nel.org>, 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:31 PM, Oleg Nesterov <oleg@...hat.com> wrote:
> On 02/13, Denys Vlasenko wrote:
>> On Wednesday 09 February 2011 15:18, Tejun Heo wrote:
>> > > > and I'm not really sure whether that's something worth achieving
>> > > > at the cost of debugging capabilities especially when we don't _have_
>> > > > to lose them.
>> > >
>> > > But we do not? I mean, at least this is not worse than the current
>> > > behaviour.
>> >
>> > I think it's worse.  With your changes, debuggers can't diddle the
>> > tasks behind group stop's back which the current users already expect.
>>
>> But this "diddling behind group stop's back" is exactly the current
>> problem with stop signals.
>>
>> 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...)
>
>      (this is correct, the tracee reports the signal=SIGSTOP, then
>       it reports it actually stopps with exit_code=SIGSTOP)

Ah, I see. Is there any way debugger can distinguish between these two
different stops?

>> 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?
>
> Yes. And I think this all should be fixed.
>
> Although, depending on how we change the kernel, strace may need the
> fixes too.

Exactly my thoughts. strace must not try to inject another SIGSTOP
when it sees the second SIGSTOP event. Currently, it does,
because it has no way to understand that the second one
*is not a signal delivery*.

-- 
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/