This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1627825555-1348781742=:4426 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 27 Sep 2012, [utf-8] Dag-Erling Sm=C3=B8rgrav wrote: > RW <[email protected]> writes: >> static __inline uint64_t >> get_cyclecount(void) >> { >> struct bintime bt; >> >> binuptime(&bt); >> return (bt.frac ^ bt.sec); >> >> } > > Why the heck does it xor the integer and fractional parts together? > That makes no sense at all. I would have used ((uint64_t)bt.sec << 32 | > bt.frac >> 32). It wraps around after 136 years' uptime, but hey, you > can't win them all. Because most of the entropy is in the fractional part, and most of it may be in the low 32 bits that you want to discard. Even if the hardware timecounter has a low frequency, ntp adjustments at a very low rate would put more entropy in the low bits than the high bits. Scaling of the hardware timecounter will probably also make the low bits nonzero, but its rate probably won't be so low as to not stir all of the available entropy into the high bits. While booting, the seconds part will only change a few times, so the entropy in it is especially low, but your way reserves 32 bits for it. Low-end systems with no hardware cycle counters may be so slow to boot that binuptime() gives as much entropy as entropy as a faster system using a hardware cycle counter. Calling binuptime() a lot is a good way to keep them slow. The above is missing the pessimizations entropy differences that i386 has. i386 get_cyclecount() used to return rdtsc() if (tsc_present), with all calls inline. Otherwise, it used binuptime() and xor as above. Now it calls the generic cpu_ticks(), which is non-inline and further pessimized using function pointers and other methods (cpu_ticks is a function pointer ...). The entropy differences are that cpu_ticks is not affected by ntp even when it is based on a timecounter. ntp won't be running at boot time, and later some of the entropy changes that it makes are negative, since it is trying to sync with the predictable real time. bt.bt_^H^H^Hsec is also very predictable. Bruce --0-1627825555-1348781742=:4426 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]" --0-1627825555-1348781742=:4426--