Messages in this thread | | | Date | Sun, 22 Sep 2013 17:40:39 -0400 | From | Theodore Ts'o <> | Subject | Re: [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded |
| |
On Sun, Sep 22, 2013 at 02:21:48PM -0700, H. Peter Anvin wrote: > Is this really an improvement on a system with plenty of entropy? Would it not make more sense to modulate this bad on entropy production rates? > > Also, the urandom pool is only reseeded once per read, no matter how large...
I added this after observing using the random driver's tracepoints to measure how the entropy pool behaves on a desktop system. It turns outs the Chrome browser requests a truly amazing amount of entropy using /dev/urandom. Enough so that while you are reading GMail or using G+, the available entropy in the input pool is always running at minimum levels. (i.e., it never gets above 192 bits before we do a catatrophic reseed and it drops down to 128 bits.)
I'm not sure what the heck it is doing --- maybe it is using /dev/urandom to generate random padding values? I can't believe it is opening new SSL connetions that quickly. So this might be a Chrome bug, and I can talk to some Chrome developers when I get into work tomorrow. But in the case of badly behaved applications, this is useful.
It results in more entropy building up in the input pool before we do a reseed, so it should result in better "catastrophic reseeding", and it means that there is more entropy available in the input pool for use by the /dev/random pool, even if /dev/urandom is being used in what might be arguably considered an abusive fashion.
You can test this by applying the patch, and observing the value of /proc/sys/kernel/random/entropy_avail over time while running a Chrome browser (and there may be other userspace applications which are as aggressive in the use of /dev/urandom). The compare it after running the command "echo 0 > /proc/sys/kernel/random/urandom_min_reseed_secs", which will restore the original pre-patch behaviour.
- Ted
| |