Entropy from disks

[Oliver Xymoron <oxymoron@waste.org>]

I just noticed:

http://linux.bkbits.net:8080/linux-2.5/cset@1.858?nav=index.html|ChangeSet@-2d

Since you're touching the disk entropy code, please read this, which
is one of the few papers on the subject:

http://world.std.com/~dtd/random/forward.ps

The current Linux PRNG is playing fast and loose here, adding entropy
based on the resolution of the TSC, while the physical turbulence
processes that actually produce entropy are happening at a scale of
seconds. On a GHz processor, if it takes 4 microseconds to return a
disk result from on-disk cache, /dev/random will get a 12-bit credit.

My entropy patches had each entropy source (not just disks) allocate
its own state object, and declare its timing "granularity".

There's a further problem with disk timing samples that make them less
than useful in typical headless server use (ie where it matters): the
server does its best to reveal disk latency to clients, easily
measurable within the auto-correlating domain of disk turbulence.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.."