Teach util/entropy.c about other APIs

[cperciva]

Linux 3.17+ has getrandom(2). Linux also has getentropy(3), which theoretically behaves the same way as the getentropy(2) in OpenBSD 5.6+. FreeBSD has the kern.arandom sysctl. iOS has SecRandom. Windows has CryptGenRandom.

[gperciva]

Is the idea that we use those other APIs instead of /dev/urandom and only fall back to that if they fail?

[cperciva]

On 04/21/18 11:38, Graham Percival wrote: Is the idea that we use those other APIs instead of |/dev/urandom| and only fall back to that if they fail?

Good question. If the other APIs are available, we should use them. If they're available and fail, we should error out -- because they shouldn't ever fail. If we don't know if the other APIs are available, I guess we can try them and if we get ENOSYS or ENOENT or whatever means "this isn't available", then yes we should fall back to trying /dev/urandom.

…

-- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid

[gperciva]

I'm guessing that you'll want a

entropy_linux_getrandom.c

(like alg/sha256_shani.c or crypto/crypto_aes_aesni.c). Do you think that should stay in the util/ directory, or should we move it to a new entropy/ directory? i.e. the first step would be moving util/entropy.{ch} to entropy/entropy.{ch}.

(I've had this code ready to go for a while, but I thought that we should get the current round of releases done before adding it.)

[cperciva]

I'd prefer to keep it in /util/. In general, that's where non-POSIX bits belong.