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: <20110214151340.GP18742@htj.dyndns.org>
Date:	Mon, 14 Feb 2011 16:13:40 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Denys Vlasenko <vda.linux@...glemail.com>
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

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.

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

Thanks.

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