Date: Tue, 3 Jul 2018 15:36:59 +0200 From: Florian Weimer <fweimer@...hat.com> To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org> Subject: Re: arc4random/csprng 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.