Messages in this thread | | | Date | Tue, 29 Oct 2002 11:10:12 -0600 | From | Oliver Xymoron <> | Subject | Entropy from disks |
| |
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.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |