Date: Wed, 16 Mar 2011 17:00:42 +0300 From: Maxim Dounin <mdounin@mdounin.ru> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Jung-uk Kim <jkim@FreeBSD.org> Subject: Re: svn commit: r219672 - in head: share/man/man9 sys/i386/include Message-ID: <20110316140042.GN99496@mdounin.ru> In-Reply-To: <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> <20110316163507.F4107@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello! On Wed, Mar 16, 2011 at 04:44:35PM +1100, Bruce Evans wrote: > 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. The problem is initial random number generator initialization (random(9) and acr4random(9)) and various early boot things which use random. Most notably it's stack protector (which has to be initialized as early as possible, and requires special handling of code which is run before it's initialized), but there are also other things to care about - AFAIR booting from nfs uses the same ports without entropy and so on. Right now the only entropy used at early boot are from get_cyclecount() call, which has at least some entropy on most platforms (notable exceptions are arm and i386 with i486 cpus). With dummy timecounter there are no entropy at early boot. After boot everything is eventually reseeded (random(9) at proc0_post(), arc4random(9) and /dev/random at userland startup scripts) and becomes safe. > 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. If you want to change get_cyclecount() to be alias to binuptime() - we may consider adding another machdep call to extract early entropy. I still not quite understand the reasons though. I consider binuptime() to be some (bad one) fallback for get_cyclecount() on platforms which has no hardware counter available. Moving all platforms to bad fallback looks strange. Maxim Dounin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110316140042.GN99496>