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
