[RESEND PATCH] crypto: add option to use getrandom()

[Lubomir Rintel]

On Sun, 2017-11-26 at 13:49 +0200, Jouni Malinen wrote:
> On Mon, Oct 16, 2017 at 09:33:07AM +0200, Lubomir Rintel wrote:
> > According to random(4) manual, /dev/random is essentially deprecated on Linux
> > for quite some time:
> > 
> >   The /dev/random interface is considered a legacy interface, and
> >   /dev/urandom is preferred and sufficient in all use cases, with the
> >   exception of applications which require randomness during early boot time;
> >   for these applications, getrandom(2) must be used instead, because it will
> >   block until the entropy pool is initialized.
> 
> 'man 4 random' on Ubuntu 16.04 does not have such language, so I'm not
> sure I'd agree about the "quite some time" part..
> 
> > An attempt to use it would cause unnecessary blocking on machines
> > without a good hwrng even when it shouldn't be needed. Since Linux 3.17,
> > a getrandom(2) call is available that will block only until the
> > randomness pool has been seeded.
> 
> What unnecessary blocking are you referring to here? /dev/random is
> opened in non-blocking mode and more data is fetched from it once it
> becomes available. How would getrandom(2) help here?

Poor wording on my side. What I meant here is that the actual service
provided by hostapd is not operational, not that the daemon is blocked
on a system call.

The issue I've encountered was that hostapd would stop working after a
few restarts on a virtual machine (used for regression testing). My
understanding was hardware randomness pool is a rather scarce resource
in some setups and should be used with caution. (The actual fix was, of
course, exposing a hwrng via virtio channel from the hypervisor.)

> Please also note that I won't be accepting changes that would
> practically move from /dev/random to /dev/urandom pool without very
> thorough explanation on how that would not have a negative impact on
> security especially as far as key derivation is concerned (this data is
> used to generate encryption keys).

Fair enough. I'm not really qualified to provide an explanation more
technical than pointing to the random(4) manual and thus will not try
to get this merged anymore.

Thanks,
Lubo