Date: Fri, 28 Sep 2012 07:35:42 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: freebsd-security@freebsd.org, RW <rwmaillists@googlemail.com> Subject: Re: Collecting entropy from device_attach() times. Message-ID: <20120928062245.K4426@besplex.bde.org> In-Reply-To: <86pq57o7ps.fsf@ds4.des.no> References: <20120918211422.GA1400@garage.freebsd.pl> <20120919192836.3a60cdfd@gumby.homeunix.com> <863923pzgi.fsf@ds4.des.no> <CAG5KPzwhq4UzPxbx74vX5KKtqC4tWkTsKAHjGDsdD8MqJVVkRg@mail.gmail.com> <20120927125956.0594fa73@gumby.homeunix.com> <86pq57o7ps.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
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-1627825555-1348781742=:4426
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
On Thu, 27 Sep 2012, [utf-8] Dag-Erling Sm=C3=B8rgrav wrote:
> RW <rwmaillists@googlemail.com> writes:
>> static __inline uint64_t
>> get_cyclecount(void)
>> {
>> struct bintime bt;
>>
>> binuptime(&bt);
>> return (bt.frac ^ bt.sec);
>>
>> }
>
> Why the heck does it xor the integer and fractional parts together?
> That makes no sense at all. I would have used ((uint64_t)bt.sec << 32 |
> bt.frac >> 32). It wraps around after 136 years' uptime, but hey, you
> can't win them all.
Because most of the entropy is in the fractional part, and most of it
may be in the low 32 bits that you want to discard. Even if the
hardware timecounter has a low frequency, ntp adjustments at a very
low rate would put more entropy in the low bits than the high bits.
Scaling of the hardware timecounter will probably also make the low
bits nonzero, but its rate probably won't be so low as to not stir
all of the available entropy into the high bits.
While booting, the seconds part will only change a few times, so the
entropy in it is especially low, but your way reserves 32 bits for it.
Low-end systems with no hardware cycle counters may be so slow to boot
that binuptime() gives as much entropy as entropy as a faster system
using a hardware cycle counter. Calling binuptime() a lot is a good
way to keep them slow.
The above is missing the pessimizations entropy differences that i386
has. i386 get_cyclecount() used to return rdtsc() if (tsc_present),
with all calls inline. Otherwise, it used binuptime() and xor as above.
Now it calls the generic cpu_ticks(), which is non-inline and further
pessimized using function pointers and other methods (cpu_ticks is a
function pointer ...). The entropy differences are that cpu_ticks is
not affected by ntp even when it is based on a timecounter. ntp won't
be running at boot time, and later some of the entropy changes that it
makes are negative, since it is trying to sync with the predictable real
time. bt.bt_^H^H^Hsec is also very predictable.
Bruce
--0-1627825555-1348781742=:4426--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120928062245.K4426>