From: Stephan Mueller <smueller@chronox.de>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-kernel@vger.kernel.org, herbert@gondor.apana.org.au,
andi@firstfloor.org, sandyinchina@gmail.com,
cryptography@lakedaemon.net, jsd@av8n.com, hpa@zytor.com,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs
Date: Mon, 02 May 2016 09:00:22 +0200 [thread overview]
Message-ID: <1876896.u5f6KW2BnX@tauon.atsec.com> (raw)
In-Reply-To: <1462170413-7164-3-git-send-email-tytso@mit.edu>
Am Montag, 2. Mai 2016, 02:26:52 schrieb Theodore Ts'o:
Hi Theodore,
I have not digested the patch set yet, but I have the following questions to
your patch set.
> On a system with a 4 socket (NUMA) system where a large number of
> application processes were all trying to read from /dev/urandom, this
> can result in the system spending 80% of its time contending on the
> global urandom spinlock. The application have used its own PRNG, but
> let's try to help it from running, lemming-like, straight over the
> locking cliff.
- initialization: In my DRBG based patch-set I tried serialize the
initialization of the per-NUMA node RNGs as follows: first the node 0 pool is
seeded completely, followed by the other nodes in a completely serial fashion.
If during that initialization time, say, node 3 wants some random number, but
the RNG for node 3 is not yet fully seeded, it goes back to the "default" RNG
of node 0. This way, it is ensured that we try to have properly seeded RNGs
even during heavy load at boot time. Would that make sense here?
- reseed avalanche: I see that you added a time-based reseed code too (I am
glad about that one). What I fear is that there is a reseed avalanche when the
various RNGs are seeded initially closely after each other (and thus the
reseed timer will expire at the same time). That would mean that they can be
reseeded all at the same time again when the timer based threshold expires and
drain the input_pool such that if you have many nodes, the input pool will not
have sufficient capacity (I am not speaking about entropy, but the potential
to store entropy) to satisfy all RNGs at the same time. Hence, we would then
have the potential to have entropy-starved RNGs.
- entropy pool draining: when having a timer-based reseeding on a quiet
system, the entropy pool can be drained during the expiry of the timer. So, I
tried to handle that by increasing the timer by, say, 100 seconds for each new
NUMA node. Note, even the baseline of 300 seconds with CRNG_RESEED_INTERVAL is
low. When I experimented with that on a KVM test system and left it quiet,
entropy pool draining was prevented at around 500 seconds.
Ciao
Stephan
next prev parent reply other threads:[~2016-05-02 7:00 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 6:26 [RFC PATCH 0/3] random: replace urandom pool with a CRNG Theodore Ts'o
2016-05-02 6:26 ` [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG Theodore Ts'o
2016-05-03 8:50 ` Stephan Mueller
2016-05-04 16:54 ` Jeffrey Walton
2016-05-04 17:30 ` tytso
2016-05-04 17:52 ` H. Peter Anvin
2016-05-03 9:36 ` Stephan Mueller
2016-05-04 6:24 ` Stephan Mueller
2016-05-04 14:40 ` Jeffrey Walton
2016-05-04 17:49 ` tytso
2016-05-04 18:22 ` Jeffrey Walton
2016-05-04 18:29 ` H. Peter Anvin
2016-05-04 19:07 ` tytso
2016-05-04 20:53 ` H. Peter Anvin
2016-05-04 21:42 ` John Denker
2016-05-04 21:52 ` better patch for linux/bitops.h John Denker
2016-05-05 1:35 ` Jeffrey Walton
2016-05-05 2:41 ` H. Peter Anvin
2016-05-05 2:54 ` Jeffrey Walton
2016-05-05 3:08 ` H. Peter Anvin
2016-05-05 3:30 ` Jeffrey Walton
2016-05-05 3:50 ` Theodore Ts'o
2016-05-05 4:03 ` Jeffrey Walton
2016-05-05 6:35 ` H. Peter Anvin
2016-05-05 16:15 ` UB in general ... and linux/bitops.h in particular John Denker
2016-05-05 17:32 ` Andi Kleen
2016-05-06 2:25 ` Jeffrey Walton
2016-05-05 21:34 ` better patch for linux/bitops.h Sandy Harris
2016-05-05 22:18 ` tytso
2016-05-05 22:22 ` H. Peter Anvin
2016-05-05 22:38 ` H. Peter Anvin
2016-05-06 0:13 ` H. Peter Anvin
2016-05-04 21:56 ` [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG H. Peter Anvin
2016-05-04 22:06 ` linux/bitops.h John Denker
2016-05-04 23:06 ` linux/bitops.h Andi Kleen
2016-05-05 0:13 ` linux/bitops.h John Denker
2016-05-05 1:20 ` linux/bitops.h Jeffrey Walton
2016-05-05 1:27 ` linux/bitops.h H. Peter Anvin
2016-05-05 0:30 ` linux/bitops.h H. Peter Anvin
2016-05-05 0:48 ` linux/bitops.h Linus Torvalds
2016-05-06 20:08 ` linux/bitops.h Sasha Levin
2016-05-06 20:07 ` linux/bitops.h Sasha Levin
2016-05-06 20:25 ` linux/bitops.h H. Peter Anvin
2016-05-06 20:30 ` linux/bitops.h H. Peter Anvin
2016-05-02 6:26 ` [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs Theodore Ts'o
2016-05-02 7:00 ` Stephan Mueller [this message]
2016-05-02 12:50 ` Theodore Ts'o
2016-05-02 13:48 ` Theodore Ts'o
2016-05-02 13:53 ` Stephan Mueller
2016-05-02 6:26 ` [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler Theodore Ts'o
2016-05-02 9:00 ` Jeffrey Walton
2016-05-02 9:14 ` Stephan Mueller
2016-05-02 12:56 ` Theodore Ts'o
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=1876896.u5f6KW2BnX@tauon.atsec.com \
--to=smueller@chronox.de \
--cc=andi@firstfloor.org \
--cc=cryptography@lakedaemon.net \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=jsd@av8n.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandyinchina@gmail.com \
--cc=tytso@mit.edu \
/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.