Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ