On Mon, Jan 14, 2013 at 03:42:42PM +0200, Marko Kreen wrote: > On Mon, Jan 14, 2013 at 3:00 PM, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
