svn commit: r219672 - in head: share/man/man9 sys/i386/include
Maxim Dounin
mdounin at mdounin.ru
Wed Mar 16 15:32:20 UTC 2011
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
More information about the svn-src-head
mailing list