Re: [PATCH] (0/4) Entropy accounting fixes

[David Brownell <david-b@pacbell.net>]

 > Questionable Sources and Time Scales
 > ------------------------------------
 >
 >  Due to the vagarities of computer architecture, things like keyboard
 >  and mouse interrupts occur on their respective scanning or serial
 >  clock edges, and are clocked relatively slowly. Worse, devices like
 >  USB keyboards, mice, and disks tend to share interrupts and probably
 >  line up on USB clock boundaries.

Last time I looked, USB didn't feed into the pool of randomness at
any level ... certainly none of the host controller drivers do, and
I didn't notice any drivers layered on top of those bus drivers
doing so either.  That includes keyboards, mice, and disks; as well
as network devices, webcams, and more.  So that "worse" isn't real.

It's likely correct that the host controller drivers don't use the
SA_SAMPLE_RANDOM flag: they're effectively sharing interrupts from
many kinds of devices, some of which may be very predictable (like
webcams).  But it might be OK for for some of those layered drivers
(HID, storage, ...) to act as entropy sources ... if such timescale
issues get addressed!  Maybe an URB_SAMPLE_RANDOM flag would be the
right kind of model.

FWIW, interrupts for OHCI and UHCI occur on frame (1 msec) boundaries,
according to their specs, though one person said he saw one vendor's
OHCI silicon doing interrupts more often.  For EHCI (USB 2.0) it's
tunable from 1 to 64 microframes, where there are 8 microframes per
frame.  (Linux defaults EHCI latency to 1 microframe == 125 usec.)

- Dave