On Wed, 16 Mar 2011, Maxim Dounin wrote:
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:33 pm, Maxim Dounin wrote:
Note that on early boot only dummy timecounter available, and
binuptime() has no entropy.
...
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.
...
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.
I see. I thought that counters were almost useless for entropy. But
the TSC normally has a very high frequency, so there is some entropy
in its low bits. I think timecounters preserve all the bits of the
low-level counter in some form (this is possible since bintimes have
even more bits than the TSC). So binuptime() should give about the
same entropy as rdtsc() when the timecounter is the TSC. But the
timecounter usually isn't the TSC. Its low-level timer usually
has a relatively low frequency (14 MHz for ACPI-fast), so it doesn't
have much entropy in its low bits, and binuptime() doesn't work well
for gathering entropy even if the timecounter is not the dummy one.
I think it is bogus that get_cyclecount(9) even mentions monotonicity.
It emphasizes monotonicy and doesn't mention entropy (except indirectly
by saying that SMP may have CPUs with independent monotonic sequences).
If you want to change get_cyclecount() to be alias to binuptime()
- we may consider adding another machdep call to extract early
entropy.
Much better to name it extract_early_entropy() than
get_monotonic_cyclecount().
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.
Maybe the dummy timecounter was not the main problem since other
counters take over soon enough, but other counters don't give enough
entropy unless they are high frequency which is rare.
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"