Date: Thu, 26 Jan 2012 22:13:41 +0400 From: Andrey Chernov <ache@FreeBSD.ORG> To: John Baldwin <jhb@FreeBSD.ORG>, Mark Murray <markm@FreeBSD.ORG>, src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG Subject: Re: svn commit: r230230 - head/sys/dev/random Message-ID: <20120126181340.GA93157@vniz.net> In-Reply-To: <20120126175243.GA19199@zim.MIT.EDU> References: <E1Rny2A-000C3x-O6@groundzero.grondar.org> <20120126143819.GA88677@vniz.net> <20120126155626.GA92229@vniz.net> <201201261132.38320.jhb@freebsd.org> <20120126165521.GA92622@vniz.net> <20120126175243.GA19199@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 26, 2012 at 12:52:43PM -0500, David Schultz wrote: > Why complicate things with atomics at all? A race might result in > arc4random(9) being seeded multiple times, but that's harmless. Multiply seeding in line is harmless, just waste of time and resources. Other case is one missing seeding when variable is set concurrently with its read. I see no complication using atomic. Latest version is even shorter than previous ones. > The race that worries me is that consumers that call arc4random() > before it is properly seeded will get predictable numbers. To fix > that robustly, we'd either have to move arc4random() into the > random module (tricky given all the places where it's used), or > make the random module a mandatory part of the kernel. I already vote for second option for various reasons. The problem still is more complicated, because arc4random() used very early in the net code and can't wait until yarrow harvests enough entropy, especially for net boot cases. -- http://ache.vniz.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120126181340.GA93157>