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-1241331444-1348789389=:5001 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 28 Sep 2012, [utf-8] Dag-Erling Sm=C3=B8rgrav wrote: > Bruce Evans <[email protected]> writes: >> "Dag-Erling Sm=C3=B8rgrav" <[email protected]> writes: >>> RW <[email protected]> writes: >>>> binuptime(&bt); >>>> return (bt.frac ^ bt.sec); >>> Why the heck does it xor the integer and fractional parts together? >> Because most of the entropy is in the fractional part, > > This is not about entropy, it's about implementing get_cyclecount() on a > platform that doesn't have a TSC. It's supposed to be monotonic, and > this implementation clearly isn't. Even when bt.sec is small enough Its monotonicity and documentation of same is a bug. > that it doesn't affect significant digits of bt.frac (which should be > most of the time, unless the resolution of the underlying timecounter > exceeds ~2^32 Hz), get_cyclecount() will go backward every time a new > second ticks over. Its implementation demonstrates that it was never actually monotonic. Even rdtsc() isn't necessarily monotonic. Its comment in at least the i386 version still says that it "Return[s] contents of an in-cpu fast counter as a sort of "bogo-time" for random- harvesting purposes". This has rotted in various ways: - on i386 without tsc_present, it never used an in-cpu fast counter (since there is none) - on i386, without tsc_present, it now uses the generic cpu_ticks() and gets whatever that gives, which happens to be a more monotonic less bogus time that before, and which doesn't have the xor hack. - on i386, with tsc_present, it now uses the generic cpu_ticks() and gets whatever that gives, which happens to be the same in-cpu fast counter as before. It shouldn't be commenting about what cpu_ticks() [doesn't] do. - its man page says that it uses a "register available in most modern CPUs to return a value that is monotonically increasing inside each CPU", and explicitly documents that each CPU gives a separate monotonic sequence. A strict reading of this says that it doesn't exist on non-modern CPUs or on some modern CPUS. Bugs in this include: - over-specification of implementation details. Lots of bugs in the details: - at least in i386, the value isn't necessarily increasing even with in each CPU, since rdtsc() isn't serialized and maybe something resets the register. The implementation just uses rdtsc() without worrying about these points. - on more modern CPUs, the values are synced, so the sequences aren't separate. - guaranteeing monotonicity. - it is now abused for non-random-harvesting purposes, and some of these require it to be monotonic. These places mostly just want a timestamp for debugging and should be using microtime(). See one of my old mails for full details of this and more details of the bogusness of get_cyclecount(). I should have objected more strongly when it was implemented. Just using binuptime() was adequate iff the timecounter hardware is the same as the cycle counter (TSC on x86). A TSC usable for timecounter hardware is normal now. I don't like cpu_tick() either, but it solves the efficiency problem with the timecounter hardware not being the cycle counter. It solves them for use mainly in thread runtime accounting, but is usable for get_cyclecount() too, and is in fact used for get_cyclecount() on i386 (get_cyclecount() just wraps it and no one except bde cares about the inefficiency of this). cpu_tick() is undocumented, so there are no bugs in its man page to fix. Bruce --0-1241331444-1348789389=:5001 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-1241331444-1348789389=:5001--