Re: getrandom syscall

[Rich Felker <dalias@libc.org>]

On Wed, Jan 28, 2015 at 11:43:17AM -0600, Brent Cook wrote:
> Here is the wrapper in LibreSSL for getrandom, to hopefully lend to
> the discussion:
> 
> https://github.com/libressl-portable/openbsd/blob/master/src/lib/libcrypto/crypto/getentropy_linux.c#L194

This version is failing to set errno when rejecting len>256, which
looks bad.

> It tries to avoid a couple of possible issues. FIrst, while <= 256
> byte getrandom should not interrupt, it appears that if the kernel
> entropy pool has not been initialized yet, it would still return EINTR
> if called early enough in the boot process. How likely this is in
> practice, I don't know.

You mean it would block and be subject to EINTR if a signal occurs? In
this case I would think you'd probably _want_ the EINTR to cause it to
fail. I can imagine an early-boot program using SIGALRM to prevent
waiting too-long/forever for entropy that's not going to arrive.

> Then, to avoid modifying errno even though there was an actual
> success, the wrapper restores the previous errno value when it
> succeeds.

Avoiding modification of errno when the call succeeds is not necessary
or desirable. Callers should not be assuming errno is untouched after
success.

> I just realized that the length check in getentropy_getrandom() is
> redundant, since it is checked earlier in getentropy() as well, but
> hopefully this is helpful.

Indeed, that masks the issue I mentioned above.

So, their version of getentropy is aiming to provide a meaningful
result even on systems that don't have SYS_getrandom. Should we be
doing the same?

> If a getentropy() were added to musl libc, but in such a way that it
> might fail on older kernels, that would cause some problems with
> LibreSSL, and now OpenNTPD. They will both try to use getentropy()
> with arc4random() if it is found in a system, and arc4random() will
> treat a getentropy() failure as fatal.

Yes, this sounds bad. So what fallbacks should we implement? Do we
need a strong CSPRNG on top of AT_RANDOM?

Rich