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

[Warner Losh]

On Aug 18, 2013, at 2:02 PM, Mark R V Murray wrote:
> On 18 Aug 2013, at 20:27, Tim Kientzle <tim at kientzle.com> wrote:
>> But clearly some people really want to be able to
>> force /dev/random to be the unconditioned output
>> of a particular HW RNG.  I don't know if this is a
>> good idea or not, but clearly there are people who
>> want this.
> 
> Agreed. (This includes my change of position on the
> subject.)
> 
> Others want Yarrow/Fortuna no matter what.

If we're going to allow passthrough, we should require the kernel config to explicitly do something to get pass through.

nodevice yarrow
device random_passthrough

would be my suggestion.

>> I am NOT claiming the old blocking /dev/random is
>> "good"; just that it is not an entirely unacceptable failure
>> mode for badly mismatched kernel/hardware combinations.
>> Keep in mind such mismatches may happen accidentally:
>> add-on HW RNG cards can fail.
> 
> True. Yarrow and Fortuna were designed to shield against
> those very failure modes. They treat ALL entropy sources
> as suspect and endeavour to be secure irregardless.
> 
> I propose two-route device:
> 
> Route 1 (SW):
>    Yarrow/Fortuna (choosable between the two for now),
>    and a fallback for Route 2. It should be possible to
>    build a kernel without this route.
> 
> Route 2 (HW):
>    Minimally-processed randomness directly from a dedicated
>    source, similar to the rdrand/ivy device, but with the
>    actual source abstracted. If no suitable source is
>    available, then this whole route fails. This is where
>    some useful "pluggability" can come. If this fails to
>    fall back; then perhaps a "I don't care" vs "PANIC!!"
>    fallback can be supplied. Here lie the dragons.

I'd go so far as to say that if you have random in your kernel, then you need to specify some "filter" or you get a compile-time error. Specifying yarrow via DEFAULTS or std.foo is fine by me, since both of those can be overriden fairly easily....  I'd also think we'd want to FAIL_PANIC or FAIL_BLOCKING, and have that choice hard wired at some level too, to be explicit about things. But maybe that's gilding things a bit too much and a tunable would suffice...

Warner