Re: Collecting entropy from device_attach() times.

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 <[e-mail]>
> wrote:
> > RW <[e-mail]> writes:
> >> "Dag-Erling Sm=F8rgrav" <[e-mail]> 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.
_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[e-mail]"