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

[Maxim Dounin]

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