Syscall based entropy

[Matt Johnston]

On Wed, Dec 30, 2015 at 03:50:34AM +0100, Guilhem Moulin wrote:
> The problem arise because reading from /dev/urandom doesn't block when
> the entropy pool hasn't been properly initialized.  As a workaround,
> dbrandom.c:seedrandom implements its own logic to try to properly seed
> the pool.  I wonder if you have considered to use getrandom(2) [1] on
> Linux ≥3.17?  AFAICT it has the semantics one would naively expect from
> reading from /dev/urandom.  I could provide with a patch if there is
> interest.  (OpenBSD has its own getentropy() syscall, but I don't have
> access to an OpenBSD box though.)

Hi Guilhem,

Using getrandom() is on my todo list - I'd be glad to take a
patch. I think the best behaviour would be to call
getrandom() on urandom with GRND_NONBLOCK in a loop
printing a warning to dropbear_log() if it is blocking (not
yet initialised) and keep waiting. dbrandom.c process_file()
already has some logic like that for reading from
/dev/[u]random with select(). The code would need to
fallback if getrandom() isn't a valid syscall - perhaps it
should just use syscall(), I'm not sure how widespread
getrandom() support is in glibc/uclibc/musl - I'm sure there
are systems with kernels newer than their libc.
See the code for clock_gettime() in dbutil.c as a similar
situation.

Dropbear already feeds the private keys into the random
pool, so the risk from a bad boot-time RNG is reduced, at
leat for the server. 
The extra sources in seedrandom() are purely opportunistic -
better than nothing, though really it would be best if
/dev/urandom blocked at boot until it's seeded (like getrandom()).

Cheers,
Matt