This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Caching of PID/TID after fork
On Thu, Oct 06, 2016 at 07:42:25PM +0200, Robert Święcki wrote:
> 2016-10-06 19:26 GMT+02:00 Rich Felker <dalias@libc.org>:
>
> >> 2. Provide some kind of symbol, which would force for TID/PID to be
> >> reloaded in glibc.
> >
> > There's an easy solution that works with existing versions of glibc
> > (and other libcs) with no new symbol or new symbol version dependency:
> > call the libc clone() function with a tiny dummy stack and a function
> > which does nothing but longjmp out to the caller.
>
> Thanks Rich, that's an interesting idea. I might use it.
>
>
> Though, IMO, the problem still exist. Some subset of non-trivial
> projects which are affected by this behavior:
>
> AFL - https://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html
> ("because the library caches the result of getpid() when initializing
> - and without a way to make it reconsider, PID-dependent calls such as
> abort() or raise() will go astray. There is also a library wrapper for
> the clone() call that does update the cached PID - but the wrapper is
> unwieldy and insists on messing with the process' stack.")
>
> LXC/Docker - https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-August/009920.html
Why can't they use the approach I just described?
Rich