Re: CVS commit: src

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

On Fri, Aug 14, 2020 at 12:53:17AM +0000, Taylor R Campbell wrote:
> New system call getrandom() compatible with Linux and others.
>
> [..]
>
> As proposed on tech-userlevel, tech-crypto, tech-security, and
> tech-kern, and subsequently adopted by core (minus the getentropy part
> of the proposal, because other operating systems and participants in
> the discussion couldn't come to an agreement about getentropy and
> blocking semantics):

Obviously, I disagree with core's decision, but let's try to be
productive about this.

I'm happy to have getrandom in NetBSD, it's a good thing. But not with
this behaviour.

1) Adopting getrandom for compatibility does not make sense.

   NetBSD's behaviour for getrandom(x, y, 0) is incompatible with Linux
   and FreeBSD _at least_ - they will unblock after the kernel receives
   an arbitrary amount of "random-ish" data. NetBSD will block forever
   until the sysadmin intervenes (by writing to /dev/random or attaching
   a forensically analyzed HWRNG, or rebooting with a seed file).

   NetBSD's behaviour for GRND_RANDOM is incompatible with FreeBSD,
   which treats it the same as getrandom(x, y, 0).

   So, NetBSD disagrees with the most popular operating systems on how
   getrandom should block.

2) The main problem raised with getentropy is that Solaris has a buggy
   implementation that projects such as Python were seeking to avoid
   (because it blocked a lot, and they preferred something that
   wouldn't).

   This is not a good reason for avoiding it, it's like saying nobody
   should ever use posix_fallocate because NetBSD 9.0's implementation
   always returns error.

3) getentropy is the preferred API for some projects. e.g, getrandom does
   not benefit Firefox at all, since it will only use getentropy or
   /dev/urandom.

4) The original argument that we need the getrandom(x, y, 0) behaviour
   to please Rust does not make sense, since Rust's randomness library
   now uses never-blocking APIs on both OpenBSD and NetBSD. Same for
   OpenSSL.

So, I suggest:

1) Make the RANDOM case for getrandom an alias for the default behaviour,
   as FreeBSD also does. It's just a nail for unsuspecting software to
   step on, and we shouldn't be copying bad ideas from Linux into our
   own syscalls.

2) Add a sysctl knob to disable getrandom's blocking behaviour, for
   systems without a forensically analyzed HWRNG. This provides an
   obvious way to ensure the system doesn't block after entropy is
   consolidated after we enter userland. Writing to /dev/random is
   non-obvious. On these systems losing the on-disk seed file is a
   critical error case that will cause blocking, currently.

3) Adopt getentropy as originally proposed. It simply makes existing
   behaviour accessible in a more obvious way (this behaviour will be in
   popular use for a long time, given our release cycles and speed at
   upstreaming patches), and also helps NSS and various other things
   get randomness in restricted environments - they currently prefer
   getentropy then urandom.

Sorry for dragging this discussion out, but I'm hoping we can reach some
form of compromise that doesn't unfairly punish systems that don't have
a HWRNG that passes the kernel's vetting.