On 8/21/13 8:55 AM, Nico Williams wrote:
OpenSSL should use pthread_atfork() and mix in more /dev/urandom into
its pool in the child-side of the fork(), Only a child-side handler
is needed, FYI, unless there's locks to acquire and release, in which
case you also need a pre-fork and parent-side handlers, or unless
fork() is just a good excuse to add entropy to the pool on the parent
side anyways :)
Yeah, it seems like a good excuse. Actually, it probably makes more
sense to only add entropy on the parent side, since the parent is likely
to live longer, and there's a good chance the child is just going to
exec() anyway, in which case adding entropy to it will have been for
nothing.
The downside with using pthread_atfork() is that it requires pthreads.
Since you pointed out there are still non-threaded libcs (at least for
static linking), that would be an issue.
Most other libraries I've seen handle this by saving the pid in a static
variable, and then comparing the current pid to it. This has the
advantage of not needing pthreads, and also of only adding the entropy
to the child if it is actually needed (i. e. it doesn't exec after fork).
For example, GnuTLS:
https://gitorious.org/gnutls/gnutls/blobs/master/lib/nettle/rnd.c#line429
libevent:
https://github.com/libevent/libevent/blob/master/arc4random.c#L413
and libottery:
https://github.com/nmathewson/libottery/blob/master/src/ottery.c#L523
The only thing that bothers me about doing the pid check is that in
theory it could still fail, although it's a really unlikely case.
Imagine a parent process that forks a child process. The child doesn't
generate any random numbers, so the reseed doesn't happen in the child.
The parent dies, and then the child forks a grandchild. In an
incredibly rare and unlucky case, the grandchild could have the same pid
as the original parent, and then the grandchild wouldn't detect it had
forked.
--Patrick
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
