Re: Waiting for Randot (or: nia and maya were right and I was wrong)

[Andreas Gustafsson <gson%gson.org@localhost>]

Taylor R Campbell wrote:
> Folks, this thread was to discuss a specific proposal about the
> getrandom and getentropy C API:
>
>    With these in mind, I propose that we change getrandom(p,n,0) so that
>    it does not block

I strongly object to this proposal.

The first google hit for "getrandom" is a Linux man page saying:

  If the urandom source has not yet been initialized, then
  getrandom() will block, unless GRND_NONBLOCK is specified in
  flags.

An application written against this man page will reasonably expect
that the data returned from getrandom(p,n,0) are unpredictable and
suitable to use for cryptographic keys.  Your proposal would mean that
such an application would generate predictable keys on NetBSD when no
entropy is available, even though it will not on Linux.  To me, that's
completely unacceptable.

>    -- under the premise that dealing with low entropy
>    is a system integration problem, not a problem that it is helpful to
>    ask an application to resolve in the heat of the sampling moment.

I agree with the premise, but it does not support your proposal.  If
system integration actually ensures that entropy is always available,
then it does not matter whether we choose the blocking or non-blocking
semantics.  Therefore, that case can't be used to justify either the
blocking or the non-blocking choice.  The choice only matters is if
such system integration has not been done, or it has failed, so that
no entropy is available.  In that case, getentropy(p,n,0) on Linux is
specified to fail closed, and it should do so on NetBSD, too.

>    I also propose we introduce never-blocking getentropy like nia@
>    briefly did last year, as an alias for getrandom(p,n,0) soon to be in
>    POSIX (https://www.austingroupbugs.net/view.php?id=1134), under the
>    premise that the never-block semantics (from the original in OpenBSD)
>    is justified again by treating low entropy as a system integration
>    problem.

I also strongly object to this proposal, for the same reasons.  The
first google hit for "getentropy" says

  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.

Again, Linux will fail closed, and NetBSD should, too.  That OpenBSD
is failing to even consider the possibility that no entropy is
available does not mean NetBSD should do the same.
-- 
Andreas Gustafsson, gson%gson.org@localhost