Date: Wed, 17 Sep 2008 12:50:25 +0400 From: Andrey Chernov <ache@nagual.pp.ru> To: current@freebsd.org Subject: Re: Is fork() hook ever possible? Message-ID: <20080917085024.GA57480@nagual.pp.ru> In-Reply-To: <20080916201932.GA59781@zim.MIT.EDU> References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 16, 2008 at 04:19:32PM -0400, David Schultz wrote: > Do you have a compelling example of why microoptimizing > arc4random() is an urgent matter? Most apps don't need > cryptographic-quality randomness thousands of times a second in > the critical path, and OpenBSD has been surviving just fine with > the calls to getpid(). arc4random() is just general PRNG. To confirm that OpenBSD itself treat arc4random() as general PRNG and use it _everywhere_ in their code instead of random() they phased out from every code piece. Contrary NetBSD don't have getpid() check at all like us now. Sooner or later some apps will want to use arc4random() intensively and having slowness here is not fundamental algo thing and can be avoided. > The patches I sent you essentially upgrade to the OpenBSD source > for arc4random() and try to minimize the diffs against them. (A > comparison of the resultant sources to OpenBSD's is below.) This > fixes several bugs, including: > > 1. silently using insecure entropy sources for jailed apps where > /dev/random is unavailable > 2. buffer sloppiness > 3. spurious restir checks > 4. the fork() problem you describe I agree with your patch (BTW you can remove unneded #define RANDOMDEV). I have exact the same plans to get rid of rs_stired and use rs_initialized only and use KERN_ARND as OpenBSD does, but can't consider or plan such big (but simple) changes in the paranoid atmosphere we already have around that unfortunate piece of code (and with review delays ~2months and increased) even with minimal step-by-step changes from our code towards OpenBSD one. Could you commit it, please? Hoping your commits will pass more easily than mine... > secteam@ already agreed to the idea of solving the fork problem as > in OpenBSD over a month ago. I really do not understand why we I don't hear about it. > need to keep trying to outdo OpenBSD with our own variant of > arc4random(). They addressed the fork() issue more than 5 years > ago and in general, they seem to be winning in terms of > correctness. > > If getpid() really winds up being a serious problem, we can solve > it in a principled way, e.g., by having the kernel fault in a > read-only page containing the current process pid, and having Speeding up getpid() by caching its value (as already discussed in this thread) looks like more general solution. -- http://ache.pp.ru/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080917085024.GA57480>