Re: arc4random/csprng

[Florian Weimer <fweimer@redhat.com>]

On 07/02/2018 10:39 PM, Rich Felker wrote:
> I haven't followed what's been happening with posix_random lately, but
> glibc has adding the arc4random interfaces and it seems reasonable
> that we should too, with the easy option to add the posix_random name
> for it and whatever interface details POSIX decides on.

Note that it's probably not going to make it into glibc 2.28 at this point.

> One topic I thought was a huge bikeshed was the whole fork-detection
> or fork-safety thing, but apparently it's not for glibc and perhaps
> other implementations because they've opted to make their csprng
> lock-free and incurred a lot of complexity with safely replacing
> pseudo-immutable state. I want to avoid most or all of this issue by
> just using a proper lock, but it might still be necessary to do some
> nasty hack for the case where fork is called from a signal handler
> interrupting the csprng. The only way to avoid that entirely is to
> block signals while the csprng runs, which is probably unjustifiably
> slow.

The main lock (for non-current kernels) is needed for the fork detection 
counters.  Fork detection is required for compatibility with 
applications which call clone/fork system calls directly, so that the 
fork handler will not run.  Without MADV_WIPEONFORK, the only reliable 
thing I came up with is the dual-counter approach (MAP_PRIVATE vs 
MAP_SHARED) and something like software TM.  At that point, avoiding the 
lock for bit generation itself is just a very minor change.

Thanks,
Florian