Collecting entropy from device_attach() times.

[RW]

On Thu, 27 Sep 2012 10:56:24 +0100
Ben Laurie wrote:

> On Thu, Sep 27, 2012 at 10:49 AM, Dag-Erling Smørgrav <des at des.no>
> wrote:
> > RW <rwmaillists at googlemail.com> writes:
> >> "Dag-Erling Smørgrav" <des at des.no> 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.
> 
> 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 

static __inline uint64_t
get_cyclecount(void)
{
        struct bintime bt;

        binuptime(&bt);
        return (bt.frac ^ bt.sec);
                        
}

In this case it will appear to be a 18 EHz counter.