Date: Wed, 16 Mar 2011 18:32:17 +0300 From: Maxim Dounin <mdounin@mdounin.ru> To: Kostik Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Jung-uk Kim <jkim@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r219672 - in head: share/man/man9 sys/i386/include Message-ID: <20110316153217.GP99496@mdounin.ru> In-Reply-To: <20110316142626.GP78089@deviant.kiev.zoral.com.ua> 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> <20110316140042.GN99496@mdounin.ru> <20110316142626.GP78089@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello! On Wed, Mar 16, 2011 at 04:26:26PM +0200, Kostik Belousov wrote: > On Wed, Mar 16, 2011 at 05:00:42PM +0300, Maxim Dounin wrote: > > 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. > proc0_post() is not called after the boot, it is executed during the boot. s/after boot/later in boot process/ > Why is the randomness for the stack protector critical at that stage ? > Most kernel threads are started after INTRINSIC_POST, at least this is > what I see from looking at kernel.h. > > Might be, the ssp initialization should be moved after SI_SUB_INTRINSIC_POST ? Random initialization used to be done at SI_SUB_INTRINSIC_POST. It was proven to be error-prone: there are at least several places in kernel which tried to use random(9) and/or arc4random(9) before SI_SUB_INTRINSIC_POST. That's why SI_SUB_RANDOM was explicitly introduced at a earliest point where we have some randomness (and stack protector initialization was moved to be after this point). While stack protector initialization may be moved later (though I doubt INSTRINSIC_POST would do - I believe we already have interrupts enabled at this point), cleanup of other places will be required, too. And I bet other similar problems will be introduced as time passes. Maxim Dounin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110316153217.GP99496>