On Thu, 27 Sep 2012 10:56:24 +0100 Ben Laurie wrote: > On Thu, Sep 27, 2012 at 10:49 AM, Dag-Erling Sm=F8rgrav <[email protected]> > wrote: > > RW <[email protected]> writes: > >> "Dag-Erling Sm=F8rgrav" <[email protected]> writes: > >> > You can't rely on the existence of a TSC. I would suggest using > >> > the fractional part of binuptime instead. > >> get_cyclecount() is supposed to be platform independent and should > >> fall-back to nanotime(9) if TSC or equivalent is absent. > > > > I just thought of another issue with get_cyclecount(). > > > > On machines with TSCs, its resolution varies with the CPU's speed > > (nominal or actual, depending on the exact model). This means that > > attachtime measurements have far lower resolution and therefore less > > entropy on slow machines than on fast ones. > > > > This doesn't mean we can't use get_cyclecount(), just that we > > shouldn't base our entropy estimates on data gathered on a fast > > system. >=20 > We should certainly see how things look on slow systems, but note that > if the resolution is lower, then the measurements will also be smaller > (assuming attachment takes similar time), and so we will claim less > entropy anyway :-) That doesn't help if the system uses binuptime(), e.g. on arm=20 static __inline uint64_t get_cyclecount(void) { struct bintime bt; binuptime(&bt); return (bt.frac ^ bt.sec); =20 } In this case it will appear to be a 18 EHz counter. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"