Re: [PATCH] /dev/random: Insufficient of entropy on many architectures

[Thorsten Glaser]

Stephan Mueller <smueller <at> chronox.de> writes:

> A monotonic counter is fully ok. Note, for /dev/random, the occurrence 
> of events delivers entropy. Thus, we have to be able to precisely 
> measure that occurrence. The timer itself does not need to deliver any 
> entropy as long as it is fast.

Rather the other way roundâ the get_cycles() value is XORd with jiffies
in drivers/char/random.c in one instance, and used alongside it in the
other, so it should NOT be derived from jiffies or the clocksource.

I think the focus on it being high-frequence enough to return a different
result every call is also too strict: better have a 16-bit 700 kHz counter
than none at all (plus, chances are very good itâs increased between calls
for drivers/char/random.c at least).

Geertâs question was probably about the requirement to be monotonicâ
other callers do do things like & 0xFF but the random code doesnât,
so something like use the 16 bit of the fast counter and fill the
slower counter into the upper bits would workâ but this is a trade-off
against interrupt speed. I canât judge whether itâs better to only
use the fast 16-bit counter, considering bus speeds and interrupt counts.
We do have jiffies too and use get_cycles() only to introduce more
uncertainty, so it may very well be enoughâ

[OT] Oh and for all who have not yet read e.g. Fefe today:
http://people.umass.edu/gbecker/BeckerChes13.pdf
Basically, RDRAND must not be used except to mix it into the pool,
now confirmed. (Kudos to Theodore and Matt for always insisting on this.)

bye,
//mirabilos

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/