linux-kernel - Re: [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130922214039.GC7321@thunk.org>
Date:	Sun, 22 Sep 2013 17:40:39 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	joern@...fs.org, macro@...ux-mips.org, ralf@...ux-mips.org,
	dave.taht@...il.com, blogic@...nwrt.org, andrewmcgr@...il.com,
	smueller@...onox.de, geert@...ux-m68k.org, tg@...bsd.de
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/