From owner-svn-src-all@FreeBSD.ORG Wed Jan 18 19:05:28 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 45EDF1065674; Wed, 18 Jan 2012 19:05:28 +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 B007B8FC20; Wed, 18 Jan 2012 19:05:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vniz.net (8.14.5/8.14.5) with ESMTP id q0IJ5PEK010000; Wed, 18 Jan 2012 23:05:25 +0400 (MSK) (envelope-from ache@vniz.net) Received: (from ache@localhost) by localhost (8.14.5/8.14.5/Submit) id q0IJ5PqU009999; Wed, 18 Jan 2012 23:05:25 +0400 (MSK) (envelope-from ache) Date: Wed, 18 Jan 2012 23:05:24 +0400 From: Andrey Chernov To: src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG Message-ID: <20120118190524.GA9847@vniz.net> Mail-Followup-To: Andrey Chernov , src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, svn-src-head@FreeBSD.ORG References: <201201162018.q0GKIADK050161@svn.freebsd.org> <20120118061943.GA80874@vniz.net> <20120118175440.GA365@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120118175440.GA365@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: Wed, 18 Jan 2012 19:05:28 -0000 On Wed, Jan 18, 2012 at 12:54:40PM -0500, David Schultz wrote: > It appears to reseed arc4random's state exactly once, at whatever > unpredictable time devrandom decides to reseed itself. Are you As fast as possible, immediatelly when we have enough good entropy. > trying to fix the problems that arise if random.ko is loaded too > late in the boot process? There is only _initial_ seeding security problem with arc4rand() and not only when random.ko is not loaded, but when it is loaded too and don't harvest enough entropy yet. All late stages don't have security problem because arc4rand() periodically reseeds itself from yarrow when ARC4_RESEED_SECONDS is expired. About random.ko loading itself, this is separate question and I already express opinion to make random.ko not optional but required kernel module. -- http://ache.vniz.net/