Date: Thu, 27 Sep 2012 12:59:56 +0100 From: RW <rwmaillists@googlemail.com> To: freebsd-security@freebsd.org Subject: Re: Collecting entropy from device_attach() times. Message-ID: <20120927125956.0594fa73@gumby.homeunix.com> In-Reply-To: <CAG5KPzwhq4UzPxbx74vX5KKtqC4tWkTsKAHjGDsdD8MqJVVkRg@mail.gmail.com> References: <20120918211422.GA1400@garage.freebsd.pl> <20120919192836.3a60cdfd@gumby.homeunix.com> <863923pzgi.fsf@ds4.des.no> <CAG5KPzwhq4UzPxbx74vX5KKtqC4tWkTsKAHjGDsdD8MqJVVkRg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <des@des.no>
> wrote:
> > RW <rwmaillists@googlemail.com> writes:
> >> "Dag-Erling Sm=F8rgrav" <des@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.
>=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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120927125956.0594fa73>