Re: [PATCH] Remove cached PID/TID in clone

[Florian Weimer <fw@deneb.enyo.de>]

* Adhemerval Zanella:

> On 08/11/2016 18:11, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>>> It's a hotspot for incorrect/broken fork detection.
>>>
>>> If you mean the assert on fork.c, I review the code and it seems
>>> unnecessary to remove the assert on child creation:
>> 
>> No, something else entirely.  OpenSSL mixes the current PID into the
>> randomness pool, in an attempt to make sure that the streams generated
>> by parent and child are different:
>> 
>>     pid_t curr_pid = getpid();
>> …
>>         if (curr_pid) {         /* just in the first iteration to save time */
>>             if (!MD_Update(m, (unsigned char *)&curr_pid, sizeof curr_pid))
>>                 goto err;
>>             curr_pid = 0;
>>         }
>> 
>> <https://github.com/openssl/openssl/blob/master/crypto/rand/md_rand.c#L283>
>> 
>> This happens at every invocation of RAND_bytes.  It may show up in
>> profiles if all the other system calls (time, gettimeofday etc.) are
>> handled by the vDSO.
>> 
>> But I suggest that this shouldn't block your change.  It's just
>> something we should be aware of.  If the kernel provides a more
>> efficient way to get the PID, we can change glibc to use it.
>> 
>> More comments about your revised patch tomorrow.
>> 
>
> Right, I referenced a quite old discussion about the pid caching
> and the randomness provided by getpid [1].

It's not about randomness per se, it's about making sure that the
randomness streams, well, fork after a fork system call.  Without it,
parent and child would give the same random bytes in the future.

The main problem is that this does not work reliably once multiple
forks are involved and the randomness pool has been seeded at an
inconvenient time:

<https://www.postgresql.org/message-id/E1UKzBn-0006c6-Ep@gemulon.postgresql.org>

Carlos has a patch to turn pthread_atfork into something that's
available without libpthread.  Maybe we should upstream it and prepare
it for handling clone (and fork from signal handlers).