Re: Caching of PID/TID after fork

[Robert Święcki <robert at swiecki dot net>]

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

-- 
Robert Święcki