linux-kernel - Re: execve-under-ptrace API bug (was Re: Ptrace documentation, draft #3)

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]

Date:	Thu, 2 Jun 2011 16:59:48 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Pedro Alves <pedro@...esourcery.com>
Cc:	Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
	jan.kratochvil@...hat.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	indan@....nu
Subject: Re: execve-under-ptrace API bug (was Re: Ptrace documentation, draft #3)

On Thu, Jun 2, 2011 at 12:57 PM, Pedro Alves <pedro@...esourcery.com> wrote:
> On Tuesday 31 May 2011 14:51:16, Oleg Nesterov wrote:
>
>> The main problem is: it is not clear do we really want EVENT_EXIT
>> in this case. I think we do, Roland thought we do not. OTOH I never
>> really the purpose of EVENT_EXIT, but this doesn't matter.
>>
>> If we decide we do want this notification (in this case), then we
>> need fixes. EVENT_EXIT is not reliable. Say, the thread can exit
>> before it dequeues SIGKILL and in this case it doesn't stop.
>> Also. If we guarantee EVENT_EXIT in this case, then probably the
>> implicit SIGKILL should not wakeup the TASK_TRACED tracee (except
>> the new PTRACE_LISTEN case).
>>
>> In short: currently I do not know what should be documented. I do
>> not know the original intent, I can only see what the code actually
>> does.
>
> Daniel Jacobowitz said when he submitted it:
>
> <http://lkml.indiana.edu/hypermail/linux/kernel/0302.0/1051.html>
>
> "PTRACE_EVENT_EXIT, which triggers in do_exit().  This is useful to quickly
>  find out where a program is making an exit syscall from, etc. - it
>  triggers before the mm is released, so we can still get backtraces et
>  cetera."

We have circa 340 syscalls. What makes exit so special that it has to have
a separate ptrace stop specially for it? People may legitimately
want to know where write() syscall happens, should we add
PTRACE_EVENT_WRITE? Rinse, repeat...

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