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.
