linux-kernel - Re: inconsistent behavior with ptrace(TRACEME) and fork/exec

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: <20081028145832.GA9211@host0.dyn.jankratochvil.net>
Date:	Tue, 28 Oct 2008 15:58:32 +0100
From:	Jan Kratochvil <jan.kratochvil@...hat.com>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	Mike Frysinger <vapier@...too.org>, linux-kernel@...r.kernel.org
Subject: Re: inconsistent behavior with ptrace(TRACEME) and fork/exec

Hi,

sorry I had a race with signal()/pause() in my last post, fixed here.


On Mon, 27 Oct 2008 18:38:16 +0100, Mike Frysinger wrote:
> On Mon, Oct 27, 2008 at 10:56, Jan Kratochvil wrote:
> > On Wed, 19 Jul 2006 21:18:29 +0200, Mike Frysinger wrote:
> >> my understanding is that if a parent forks and the child does
> >> a ptrace(TRACEME) right before doing an exec(), the kernel should always
> >> halt it and wait indefinitely for the parent to start ptracing it.
> >
> > Yes, just the parent must process the event (signal).  In your testcase the
> > parent finished before the signal could be delivered.  If the tracer exits the
> > tracee's tracing is finished and it continues freely.
> 
> no signal should have been generated.  the child should have gone
> straight to the exec and waited for the parent to process it.

Every ptrace event generates SIGCHLD.  vfork() frees the parent at the moment
the child calls exec() or _exit().  Here the child calls exec() which both
frees the parent to continue the execution AND delivers SIGCHLD with the
status WIFSTOPPED WSTOPSIG(SIGTRAP) to it.  I do not see a problem here.


> >> unfortunately, this behavior seems to be unreliable.
> >
> > Fixed the races in your code and I do not see there any problem, do you?
> > The ptrace problems/testsuite is being maintained at:
> >  http://sourceware.org/systemtap/wiki/utrace/tests
> 
> there is no race condition ... it's using vfork here remember ?

Yes but you said that you see the same problem even with fork():

On Wed, 19 Jul 2006 21:18:29 +0200, Mike Frysinger wrote:
# also, while the attached test uses vfork(), same behavior can be observed
# with fork().  


> it is impossible for the parent to have executed anything after the vfork()
> before the child made it into the exec() and gone to sleep

You must not rely on the vfork() specifics as vfork() can be just fork():
http://www.opengroup.org/onlinepubs/009695399/functions/vfork.html
APPLICATION USAGE


I hope there is no problem with the kernel at this moment, the attached
testcase works even with vfork() reliably.



Regards,
Jan

View attachment "ptrace-vfork-traceme.c" of type "text/plain" (2464 bytes)