[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <647a7190-b70b-23a2-9b3c-a24b44fcac99@redhat.com>
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.
