From owner-svn-src-head@FreeBSD.ORG Wed Mar 16 05:44:46 2011 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB9CD106566B; Wed, 16 Mar 2011 05:44:46 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 504348FC14; Wed, 16 Mar 2011 05:44:45 +0000 (UTC) Received: from c122-107-125-80.carlnfd1.nsw.optusnet.com.au (c122-107-125-80.carlnfd1.nsw.optusnet.com.au [122.107.125.80]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2G5iZtq022301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Mar 2011 16:44:42 +1100 Date: Wed, 16 Mar 2011 16:44:35 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jung-uk Kim In-Reply-To: <201103151631.34418.jkim@FreeBSD.org> Message-ID: <20110316163507.F4107@besplex.bde.org> References: <201103151714.p2FHEQdF049456@svn.freebsd.org> <20110315193306.GK99496@mdounin.ru> <201103151555.45816.jkim@FreeBSD.org> <201103151631.34418.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Maxim Dounin Subject: Re: svn commit: r219672 - in head: share/man/man9 sys/i386/include X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 05:44:46 -0000 On Tue, 15 Mar 2011, Jung-uk Kim wrote: > On Tuesday 15 March 2011 03:55 pm, Jung-uk Kim wrote: >> On Tuesday 15 March 2011 03:33 pm, Maxim Dounin wrote: >>> Hello! >>> >>> On Tue, Mar 15, 2011 at 05:14:26PM +0000, Jung-uk Kim wrote: >>>> Author: jkim >>>> Date: Tue Mar 15 17:14:26 2011 >>>> New Revision: 219672 >>>> URL: http://svn.freebsd.org/changeset/base/219672 >>>> >>>> Log: >>>> Unconditionally use binuptime(9) for get_cyclecount(9) on >>>> i386. Since this function is almost exclusively used for random >>>> harvesting, there is no need for micro-optimization. Adjust >>>> the manual page accordingly. >>> >>> Note that on early boot only dummy timecounter available, and >>> binuptime() has no entropy. >>> As a result of this change random(9) won't have entropy on early >>> boot on i386, and arc4random(9) as well. While there are no >>> known major security problems associated with it - it at least >>> makes stack protector easily bypasseable as it now (again after >>> r198295) uses well-known stack guard instead of random one. And >>> there may be other issues as well. Is dummy timecounter used for long enough to matter? I think completion of clock initialization is still bogusly late for histrotical reasons, but there is still a second or two between completion of timecounter initialization and user mode. The earlier stages of booting might take 20 seconds but should be faster, so they might not provided much more entropy from clocks. I have entropy stuff mostly turned off and often don't even have enough entropy to run ed on /etc/fstab early. Don't know if I have clock entropy turned off. >>> Hope you thought well before moving i386 to a set of platforms >>> which have no early boot randomness at all. And you have good >>> reason for doing it. I asked for moving all platforms to binuptime() so that the bugs could be seen by everyone :-). Didn't know about this bug. >> Hmm... Is bintime(9) good enough for you then? > > I guess it won't work cause boottimebin is set pretty late. Arg... > If I can't come up with something sensible, I'll revert this commit. boottimebin would make no difference since it just provides provides a few non-random bits. Bruce