On Mon, Jan 14, 2013 at 03:42:42PM +0200, Marko Kreen wrote:
> On Mon, Jan 14, 2013 at 3:00 PM, Noah Misch <noah@leadboat.com> wrote:
> > On Mon, Jan 14, 2013 at 02:21:00PM +0200, Marko Kreen wrote:
> >> Note: reading from /dev/urandom does not affect /dev/random.
> >
> > Reading from /dev/urandom drains the pool that serves /dev/random:
> >
> > $ cat /proc/sys/kernel/random/entropy_avail
> > 3596
> > $ dd iflag=nonblock bs=100 count=1 if=/dev/random of=/dev/null
> > 1+0 records in
> > 1+0 records out
> > 100 bytes (100 B) copied, 0.000174798 s, 572 kB/s
> > $ cat /proc/sys/kernel/random/entropy_avail
> > 2839
> > $ head -c10000000 /dev/urandom >/dev/null
> > $ cat /proc/sys/kernel/random/entropy_avail
> > 212
> > $ dd iflag=nonblock bs=100 count=1 if=/dev/random of=/dev/null
> > 0+1 records in
> > 0+1 records out
> > 38 bytes (38 B) copied, 0.000101439 s, 375 kB/s
>
> This slightly weakens my argument, but not completely - any
> /dev/urandom-using processes are still unaffected, but
> indeed processes using /dev/random can block. But what are those?
I don't know, really. I agree it's probably a rare thing, to the point of
trivial concern for a major release. For a backpatch, avoiding such
system-wide effects seems to me like a fair tiebreaker.
Needless to say, all three proposals I listed would be major improvements over
the present, vulnerable state.
> $ cat /proc/sys/kernel/random/entropy_avail
> 3451
> $ cat /proc/sys/kernel/random/entropy_avail
> 3218
> $ cat /proc/sys/kernel/random/entropy_avail
> 3000
> Each exec() eats from the pool on modern system.
Amusing.
Thanks,
nm
