svn commit: r219672 - in head: share/man/man9 sys/i386/include

[Kostik Belousov]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20110316/6077c4ce/attachment.pgp