H. Peter Anvin wrote:
> Those already are doing this.
They used to via IRQF_SAMPLE_RANDOM, but these are being removed
(according to Documentation/feature-removal-schedule.txt). In 2.6.39 I
can only find 10 remaining instances, out of many more network drivers.
The alternative is supposed to be calls to add_*_randomness(), but that
family of functions seems to only have one exported symbol:
add_input_randomness(), which looks like is called only for things
dealing with human input.
So network entropy is being eradicated, and nothing is being done to
replace it.
This is crazy.
Consider the case where the TSC is running in steps of 64 and you're
using the low 6 bits.
It does that? I thought it was a "time stamp counter", that is
incremented. You know, incremented by one. (Why would someone have it
jump by 64? Wiring it up on the cheap side of the clock multiplier?
What chips do that?)
Maybe this patch is not sensible. If it is only going to be called on
timer, then there is the feedback issue that will badly limit the
entropy, and if a TSC is sometimes only jumping in big steps, then the
available entropy is being masked.
Let me fall back to a different (but related) topic: eradicating
IRQF_SAMPLE_RANDOM is stupid. The only argument in favor seems to be
that the entropy estimation might be too high. But entropy estimation
is never going to be accurate. Better to credit no entropy than to
collect no entropy.
-kb
--
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
