Re: Caching of PID/TID after fork

["Robert Święcki" <robert@swiecki.net>]

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

Admittedly, they probably could... it's just the clone interface is
probably supposed to be used by projects like that (non trivial ones,
depending deeply on kernel interfaces), and it seems that the authors
of those non-trivial tools (possibly, quite experienced in the area of
computer architectures) are somewhat troubled by the current glibc
behavior.

Therefore, maybe there's some opportunity here for glibc to provide
them with an interface which might better suit their needs. In my
opinion, the path that every future developer dealing with this issue
have to take (from analyzing the kernel's __NR_clone implementation to
by-passing glibc wrapper with setjmp/longjmp) might be a bit more
complex than it should.

-- 
Robert Święcki