Re: getentropy() support

[Kurt Roeckx <kurt%roeckx.be@localhost>]

On Wed, Jun 20, 2018 at 03:49:44PM +0000, Taylor R Campbell wrote:
> > From: Kurt Roeckx <kurt%roeckx.be@localhost>
> > - It blocks when the kernel CSRNG hasn't been initialized yet.
> 
> The blocking behaviour isn't documented in
> <http://man.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2>,
> and I don't think it would be a good idea.  In particular, if a system
> call _might_ block, it should do so regularly so that the blocking
> code path is exercised, rather than only once in a great while and
> especially not during interactive testing.

For OpenBSD it's like expected behaviour, why would you return
insecure random numbers. What is the point in documenting that
it's not insecure? But if it helps, I can ask them to document that
part.

In any case, it is documented on all other operating systems:
Linux, http://man7.org/linux/man-pages/man3/getentropy.3.html

       A call to getentropy() may block if the system has just booted and
       the kernel has not yet collected enough randomness to initialize the
       entropy pool.  In this case, getentropy() will keep blocking even if
       a signal is handled, and will return only once the entropy pool has
       been initialized.

FreeBSD,
https://www.FreeBSD.org/cgi/man.cgi?query=getentropy&apropos=0&sektion=0&manpath=FreeBSD+12-current&arch=default&format=html

     Similar to reading from /dev/urandom just after boot, getentropy() may
     block until the system has collected enough entropy to seed the CSPRNG.

Solaris,
https://docs.oracle.com/cd/E88353_01/html/E37841/getentropy-2.html

   The getentropy() function is always a blocking call, it is
   expected to be used only to seed a userspace implementation of a
   random bit generator.


Kurt