random(4) plugin infrastructure for mulitple RNG in a modular fashion

[Warner Losh]

On Aug 18, 2013, at 10:53 AM, Tim Kientzle wrote:

> On Aug 18, 2013, at 4:33 AM, Dag-Erling Smørgrav wrote:
> 
>> Mark R V Murray <mark at grondar.org> writes:
>>> OK - in the context of what is currently there, it makes less sense than
>>> that; loading RDRAND/Ivy and Nehemiah simultaneously is silly …
> 
> Lots of folks build static kernels that they run on diverse
> hardware.
> 
> The hardware RNG modules should be loadable simultaneously
> and should probe and activate only if their hardware is present,
> like any other driver for real hardware.

Agreed, I made that point earlier in this thread...

>> Provided the HWRNG is of sufficient quality, the user should be allowed
>> to use it directly (through /dev/random) without Yarrow / Fortuna.
> 
> We could have kernel options to choose mixers
> (e.g., Yarrow or Fortuna) for /dev/random and
> loadable device modules for entropy sources.
> 
> Besides Yarrow and Fortuna mixers, we could then
> offer a "null mixer" option that selected the single
> "best" entropy source and passed it directly through.

I'm still wondering why timecounters aren't the right model to follow here, where you can have several compiled into the kernel and the one with the best score wins.

> Users could compile the null mixer into the kernel
> and load a single HW RNG driver to have precise
> control over /dev/random.  Interrupt harvesting would
> be the lowest-quality source as a fall back.
> 
> In particular, this has a reasonable failure mode if
> someone built a kernel with only a single HW entropy
> source and the null mixer:
>  * On hardware with that source, they would get
>     full-speed HW entropy.
>  * On hardware without that source, they would get
>     the old blocking /dev/random that we had before
>     Yarrow, the one that used only interrupt harvesting.

Assuming there was enough interrupt entropy to generate bits...

Warner