svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

[Conrad Meyer]

Hi Warner,

On Wed, Apr 17, 2019 at 10:16 AM Warner Losh <imp at bsdimp.com> wrote:
> I'm going to put a very fine point on this: any hard-requirement of entropy sources is a non-starter. If you require that, your commit will be backed out and/or hacked around by the addition of a nob in the future. It will happen. Don't pretend you can say 'but things weren't random enough' will carry the day. It will not.
>
> That's why I specifically requested a MD routine to be called when there's no source of entropy: that will let special needs folks do the right thing. It's also why I asked for a way to say "don't ever block waiting for entropy, soldier on the best you can, but set some variable that can be exposed to userland so that early in /etc/rc automation can be written to decide what to do when that condition exists: generate entropy and reboot, report it to some central control, nothing" since that will give the tools for different reactions.
>
> For our application it is *NEVER* OK to block the boot because there's not enough randomness. We'd rather solider on with crappy randomness and want the boot to proceed not matter what. We want the information that we had to make compromises along the way to make it happen so we can decide the right course of action for our appliances.

I think John's proposed big knob to disable hard-requirement of
entropy, and a warning on dmesg, pretty much covers your applications'
needs.  Do you agree?

The random framework has already got ways to register random sources;
special needs MD folks can always register their own fako fast random
source.  I.e., the randomdev entropy intake framework is already
general with room for MD-specific drivers (of which several exist
today).

Take care,
Conrad