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. 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 ? This is definitely irrelevant for usermode ssp, since the first thread enters usermode long after the INTRINSIC_POST is done. > > > 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
pgpPB6TXVCpfJ.pgp
Description: PGP signature