On Mon, 2011-06-13 at 18:06 -0400, Jarod Wilson wrote: > Many server systems are seriously lacking in sources of entropy, > as we typically only feed the entropy pool by way of input layer > events, a few NIC driver interrupts and disk activity. A non-busy > server can easily become entropy-starved. We can mitigate this > somewhat by periodically mixing in entropy data based on the > delta between multiple high-resolution clocksource reads, per: > > https://www.osadl.org/Analysis-of-inherent-randomness-of-the-L.rtlws11-developers-okech.0.html > > Additionally, NIST already approves of similar implementations, so > this should be usable in high-securtiy deployments requiring a > fair chunk of available entropy data for frequent use of /dev/random. > > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp750.pdf > (section 6.1 mentions a clock-based seed source). > > Yes, thus far, I've only bothered with x86-based clocksources, since that > is what I can test most easily. If this patch series isn't deemed totally > insane, adding support for other clocksources should be trivial. > > Also note that unless you explicitly build and load the clock-entropy > driver, there should be little or no change whatsoever to the way anything > behaves right now, its purely opt-in. There's probably room for some > improvement here, and I'm kind of outside my comfort area, but hey, it > seems to work pretty well here in my own testing, so here it is... > > Jarod Wilson (5): > random: add new clocksource entropy interface > clocksource: add support for entropy-generation function > hpet: wire up entropy generation function > tsc: wire up entropy generation function > misc: add clocksource-based entropy generation driver So this is interesting work, but I have a few questions. 1) hpet_add_entropy() and tsc_add_entropy() are basically identical. It seems there should be a generic bit of code that uses the clocksource's read() function and does the same calculation. 2) If the .entropy() functions really aren't clocksource specific, it doesn't really seem like this functionality belongs in the clocksource layer. Instead it seems it should be a layer above, that makes use of the clocksource code in a generic fashion. 3) Why are you making use of the curr_clocksource? The timekeeping code has very strict rules about what makes a clocksource usable for timekeeping. I suspect entropy generation has different requirements, and thus shouldn't lean on the curr_clocksource value (ie: TSC may be unsynced or halts in idle, and thus unusable for time, but likely still ok for entropy). 4) Further on that point, there's a likely bug: If an entropy supporting clocksource is available, clocksource_entropy_available() will return true, but if the one curr_clocksource is not the one that supports entropy, clocksource_add_entropy() won't do anything. I suspect the add_entropy function needs to scan for a entropy flagged clocksource and use it instead. 5) Does the entropy calculation need to be flagged clocksource by clocksource? Or could a generic metric be made (ie: frequency?) in order to enable such functionality on all capable clocksources automatically? thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
