Syscall based entropy

[Szabolcs Nagy]

* Matt Johnston <matt at ucc.asn.au> [2015-12-30 22:08:14 +0800]:
> 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.

there is no getrandom libc api yet
(e.g. see libc-alpha discussions:
https://sourceware.org/ml/libc-alpha/2015-11/msg00373.html
)

and the syscall number is not yet allocated for some
target archs (e.g. sh).

using raw syscall(2) can be problematic (e.g. on x32)
and it adds a kernel header dependency (for the flags).

there should be both compile-time and runtime checks
(ifdef SYS_getrandom and check for ENOSYS).

so there are some caveats, but otherwise it would be
a useful addition.

> See the code for clock_gettime() in dbutil.c as a similar
> situation.

using SYS_clock_gettime is broken: it turns a performance
critical vdso call into a slow syscall.

if you want to support old glibc then just add -lrt if
it is needed, but i think modern systems should not be
pessimized.

> 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