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

[Warner Losh]

On Aug 8, 2013, at 3:15 PM, David O'Brien wrote:

> On Thu, Aug 08, 2013 at 01:20:19PM -0600, Warner Losh wrote:
>> The sheer number of config files you changed says this is a bad idea,
>> or you are during something very wrong.
> 
> Why?  That's the sheer number of config files that have "device random"
> in them.  How it reasonable for "device random" to be in them but not
> random(4) options?

For the most part, those are wrong too.

> We did not like having to change so many config files -- the ARM kernel
> configs seems to be in need of additional refactoring.

You need to use the mechanisms that are already present in the arm kernel config files to accomplish this. You are doing it the wrong way, and I'm telling you the right way. Don't argue, just fix it then. You yourself just admitted you don't like the way you chose, why are you arguing with me about this?

>> Also, you bogusly changed way too many config files rather than the
>> underlying std.* files for the ARM port.
> 
> If that is the case, why isn't "device random" in the std.* files?

Because that was slavishly, and bogusly, copied from GENERIC on other architectures.

> Please address that before saying that random(4) options should live
> somewhere else than where "device random" lives.

No. I'm telling you the proper place to put your changes. This isn't about making a perfect system, only how you can help to get there. I won't be drawn into the perfect system argument.

>> What's wrong with having yarrow as the default, fallback mechanism. And
>> why do you have a design that seems to force one, and only one, into
>> the kernel?  The way it is now we fail bad rather than fail to yarrow
>> fallback.  This seems unwise.
> 
> How does it force 1 and only 1 into the kernel?  If there were some
> MIPS or ARM HW they would also be in the kernel.  When markm@ completes
> his Fortuna work, it could (and likely would) also live beside Yarrow.
> Or a NIST SP 800-90-A compliant HMAC_DRBG can also live in the kernel
> beside Yarrow (and Fortuna).  Obviously at the point of having more
> than one SW PRNG we'll have a selection mechanism to "break ties".
> Right now the code only handles that for HW.

Forcing one and only one into the kernel is wrong. You are approaching the problem wrong if that's a requirement. That's like saying you can have one and only one time keeping thing compiled into the kernel. You can have several, but only use one. It is use that's important here, not the number that are compiled in. Only one can be in use at any given time, true. Have a design that enforces that, not that there can be only one compiled into or loaded into the kernel at a time. This would allow a fail-safe mechanism, as well as the knobs to disable it, rather than a fail stupid mechanism you've proposed.

>> I haven't read the code in detail, but I don't see how I'd override
>> the CPU's random number unit with one from a plug-in board when it is
>> present.
> 
> Please read the code to see how that is handled in
> sys/dev/random/probe.c:random_ident_hardware().  Note that my commit did
> not change the logic here (just updated the implementation of it).  It's
> the same logic we've had since 2004 (r128059 and updated in 2012(r240135)).

If you can override it, then I fail to see why the fallback is so hard?

Warner