Hi Warner,

On Wed, Apr 17, 2019 at 10:16 AM Warner Losh <i...@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


_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to