From: "Theodore Ts'o" <tytso@mit.edu>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
joern@logfs.org, macro@linux-mips.org, ralf@linux-mips.org,
dave.taht@gmail.com, blogic@openwrt.org, andrewmcgr@gmail.com,
smueller@chronox.de, geert@linux-m68k.org, tg@mirbsd.de
Subject: Re: [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded
Date: Sun, 22 Sep 2013 17:40:39 -0400 [thread overview]
Message-ID: <20130922214039.GC7321@thunk.org> (raw)
In-Reply-To: <e665f20c-9154-4dbd-bb93-cf144922bf29@email.android.com>
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
next prev parent reply other threads:[~2013-09-22 21:41 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-22 20:38 [PATCH, RFC 00/12] random driver changes Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 01/12] random: run random_int_secret_init() run after all late_initcalls Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 02/12] random: Statically compute poolbitshift, poolbytes, poolbits Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 03/12] random: Allow fractional bits to be tracked Theodore Ts'o
2013-09-23 4:01 ` Theodore Ts'o
2013-09-23 4:03 ` H. Peter Anvin
2013-09-22 20:38 ` [PATCH, RFC 04/12] random: Account for entropy loss due to overwrites Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 05/12] random: fix the tracepoint for get_random_bytes(_arch) Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 06/12] random: optimize spinlock use in add_device_randomness() Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 07/12] random: allow architectures to optionally define random_get_entropy() Theodore Ts'o
2013-09-23 10:38 ` Stephan Mueller
2013-09-23 11:05 ` Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 08/12] random: mix in architectural randomness earlier in extract_buf() Theodore Ts'o
2013-09-23 4:11 ` H. Peter Anvin
2013-09-23 4:33 ` Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 09/12] random: optimize the entropy_store structure Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 10/12] random: cap the rate which the /dev/urandom pool gets reseeded Theodore Ts'o
2013-09-22 21:21 ` H. Peter Anvin
2013-09-22 21:40 ` Theodore Ts'o [this message]
2013-09-22 22:45 ` H. Peter Anvin
2013-09-22 23:23 ` Theodore Ts'o
2013-09-23 0:26 ` H. Peter Anvin
2013-09-22 20:38 ` [PATCH, RFC 11/12] random: speed up the fast_mix function by a factor of four Theodore Ts'o
2013-09-22 20:38 ` [PATCH, RFC 12/12] random: adjust the generator polynomials in the mixing function slightly Theodore Ts'o
2013-09-25 10:51 ` Jörg-Volker Peetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130922214039.GC7321@thunk.org \
--to=tytso@mit.edu \
--cc=andrewmcgr@gmail.com \
--cc=blogic@openwrt.org \
--cc=dave.taht@gmail.com \
--cc=geert@linux-m68k.org \
--cc=hpa@zytor.com \
--cc=joern@logfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=smueller@chronox.de \
--cc=tg@mirbsd.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.