* Matt Johnston <[email protected]> [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
