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.

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.

Hmm...  Is bintime(9) good enough for you then?

I guess it won't work cause boottimebin is set pretty late.  Arg...
If I can't come up with something sensible, I'll revert this commit.

boottimebin would make no difference since it just provides provides a
few non-random bits.

Bruce
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Reply via email to