Re: getrandom and getentropy

[nia <nia%NetBSD.org@localhost>]

On Sun, May 03, 2020 at 09:28:37PM +0000, Taylor R Campbell wrote:
> > Date: Sun, 3 May 2020 19:13:23 +0000
> > From: nia <nia%NetBSD.org@localhost>
> > 
> > Since most of the objections so far have been aimed at the design
> > and implementation of getrandom, does anyone have anything bad to say
> > about getentropy?
> 
> That's what I had in mind at the start of the thread after verifying
> _that_ most other systems implement something called getentropy, under
> the assumption that they would all agree on the semantics.
> 
> But on closer inspection, it's not clear there's a consensus on what
> the semantics is supposed to be -- apparently _what_ everyone seems to
> implement is slightly different:
> 
> - OpenBSD originally defined getentropy to be block-never, as in
>   getrandom(GRND_INSECURE)
> 
> - glibc, FreeBSD, and illumos implement block-at-boot, as in
>   getrandom(0)
> 
> - Oracle Solaris maybe implements block-often, as in traditional
>   /dev/random, but it's not clear; it might be block-at-boot (I don't
>   have source code to reference, but there is some weak evidence that
>   Oracle's getentropy is or was painfully slow, which might arise from
>   blocking repeatedly, whereas getrandom worked fine:
>   <https://bugs.python.org/issue25003>)

The thing is, I'm not convinced there's a meaningful difference between
the first two. As you said, /systems/ should be engineered to block
until enough entropy is available. block-on-boot beaviour shouldn't be
hit because the system should wait until entropy is acquired before any
application software with serious entropy needs gets initialized.

As I recall, FreeBSD only exposes the block-at-boot behaviour -
/dev/random and /dev/urandom are identical and both will always block
if accessed before there's 256 bits of entropy available.
IMO, this is fine. It's an edge case that software won't reach except
in niche situtations, and when it does get hit it's saving you from
a fairly dangerous state.

The Solaris behaviour seems like a bug, and I'm not convinced we should
let other vendors' bad implementations get in the way of us having
a good implementation. The same applies to the GRND_RANDOM behaviour.