From owner-svn-src-all@FreeBSD.ORG Thu Jan 26 18:13:44 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C62EA106566B; Thu, 26 Jan 2012 18:13:44 +0000 (UTC) (envelope-from ache@vniz.net) Received: from vniz.net (vniz.net [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 324B58FC13; Thu, 26 Jan 2012 18:13:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id q0QIDgJ5093231; Thu, 26 Jan 2012 22:13:42 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id q0QIDgOx093229; Thu, 26 Jan 2012 22:13:42 +0400 (MSK) (envelope-from ache) Date: Thu, 26 Jan 2012 22:13:41 +0400 From: Andrey Chernov To: John Baldwin , Mark Murray , src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG Message-ID: <20120126181340.GA93157@vniz.net> Mail-Followup-To: Andrey Chernov , John Baldwin , Mark Murray , src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG References: <20120126143819.GA88677@vniz.net> <20120126155626.GA92229@vniz.net> <201201261132.38320.jhb@freebsd.org> <20120126165521.GA92622@vniz.net> <20120126175243.GA19199@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120126175243.GA19199@zim.MIT.EDU> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: svn commit: r230230 - head/sys/dev/random X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 18:13:44 -0000 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/