[onerng talk] Redirect output to urandom and link random to urandom

[Paul Campbell]

On Friday, 27 May 2016 11:05:58 AM NZST alexandre wrote:
> here is the "led" :) behavior i just noticed while testing :
> 
> #with /dev/random
> #RNGD_FLAGS=" "
> #unplug / plug / wait a few seconds
> # -> led bright
> cat /dev/random > /dev/null
> # -> led dim
> 
> #unplug
> echo 0 >/proc/sys/kernel/random/urandom_min_reseed_secs
> #plug / wait a few seconds
> #-> led is bright (blink noticed too btw)
> cat /dev/urandom > /dev/null
> #-> led dim
> 
> #with /dev/urandom
> echo 60 >/proc/sys/kernel/random/urandom_min_reseed_secs
> #RNGD_FLAGS="  -o /dev/urandom "
> #unplug / plug / wait a few seconds
> #-> led is always dim
> 
> Seems like the onerng is always feeding /dev/urandom in this situation

ah I see what's happening here - rngd uses poll() to do flow control so it 
doesn't push entropy into the kernel when the kernel entropy pool is full 
(that's why OneRNG only blinks when entropy is actually consumed) - that works 
great on /dev/random, but /dev/urandom does not block in a poll() call and you 
are just continually pushing entropy into the pool that's never used because 
they overflow when the (quite small) kernel pool fills.

I think the behaviour you document above with "echo 0 >/proc/sys/kernel/
random/urandom_min_reseed_secs" is the long term desired one - I encourage 
people to use that understanding that the blinking behaviour every second is 
normal 

Actually if it was easy I'd change the kernel to have a larger input kernel 
pool and have /dev/urandom unconditionally grab data while the input pool is 
more than half, or some threshold, full, that stops it from completely 
stalling /dev/random while letting something like OneRNG that can keep it full 
most of the time feed both interfaces. However one of our goals is NOT to 
require any kernel changes to use OneRNG

	Paul