linux-kernel - 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]

Message-ID: <20110530133547.GA4739@redhat.com>
Date:	Mon, 30 May 2011 15:35:47 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Denys Vlasenko <vda.linux@...glemail.com>
Cc:	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: Ptrace documentation, draft #3

On 05/20, Denys Vlasenko wrote:
>
 ??? How tracer knows which of its many tracees _are_ threads of that
> particular process? (It may trace more than one process; it may even
> don't keep track of its tracees' thread group relations at all...)

I think the tracer should track the tgid relations if it wants to know
this. Although we can add the simple PTREAD_ request which provides some
info including tgid.

> ??? what happens if two threads execve at the same time? Clearly, only
> one of them succeeds, but *which* one? Think "strace -f" or
> multi-threaded process here:
>
>   ** we get death notification: leader died: **
>  PID0 exit(0)                            = ?
>   ** we get syscall-entry-stop in thread 1: **
>  PID1 execve("/bin/foo", "foo" <unfinished ...>
>   ** we get syscall-entry-stop in thread 2: **
>  PID2 execve("/bin/bar", "bar" <unfinished ...>
>   ** we get PTRACE_EVENT_EXEC for PID0, we issue PTRACE_SYSCALL **
>   ** we get syscall-exit-stop for PID0: **
>  PID0 <... execve resumed> )             = 0
>
> ??? Question: WHICH execve succeeded? Can tracer figure it out?

Afaics, in general the tracer can't figure it out. Well, in this
particular case the tracer can inspect the arguments when the winner
(now it is PID0) reports the syscall-exit.

Also. All threads but the winner can report PTRACE_EVENT_EXIT. But once
again, we have problems with PTRACE_EVENT_EXIT/fatal_signal_pending().

Oleg.

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