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"