LKML Archive on
help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <>
Cc: "Jason A. Donenfeld" <>,
	Greg Kroah-Hartman <>
Subject: [PATCH] random: always use batched entropy for get_random_u{32,64}
Date: Sun, 16 Feb 2020 17:18:36 +0100	[thread overview]
Message-ID: <> (raw)

It turns out that RDRAND is pretty slow. Comparing these two

  for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret))


  long buf[CHACHA_BLOCK_SIZE / sizeof(long)];
  extract_crng((u8 *)buf);

it amortizes out to 352 cycles per long for the top one and 107 cycles
per long for the bottom one, on Coffee Lake Refresh, Intel Core i9-9880H.

And importantly, the top one has the drawback of not benefiting from the
real rng, whereas the bottom one has all the nice benefits of using our
own chacha rng. As get_random_u{32,64} gets used in more places (perhaps
beyond what it was originally intended for when it was introduced as
get_random_{int,long} back in the md5 monstrosity era), it seems like it
might be a good thing to strengthen its posture a tiny bit. Doing this
should only be stronger and not any weaker because that pool is already
initialized with a bunch of rdrand data (when available). This way, we
get the benefits of the hardware rng as well as our own rng.

Another benefit of this is that we no longer hit pitfalls of the recent
stream of AMD bugs in RDRAND. One often used code pattern for various
things is:

  do {
  	val = get_random_u32();
  } while (hash_table_contains_key(val));

That recent AMD bug rendered that pattern useless, whereas we're really
very certain that chacha20 output will give pretty distributed numbers,
no matter what.

So, this simplification seems better both from a security perspective
and from a performance perspective.

Signed-off-by: Jason A. Donenfeld <>
Cc: Greg Kroah-Hartman <>
 drivers/char/random.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index c7f9584de2c8..037fdb182b4d 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2166,15 +2166,6 @@ u64 get_random_u64(void)
 	struct batched_entropy *batch;
 	static void *previous;
-#if BITS_PER_LONG == 64
-	if (arch_get_random_long((unsigned long *)&ret))
-		return ret;
-	if (arch_get_random_long((unsigned long *)&ret) &&
-	    arch_get_random_long((unsigned long *)&ret + 1))
-	    return ret;
 	batch = raw_cpu_ptr(&batched_entropy_u64);
@@ -2199,9 +2190,6 @@ u32 get_random_u32(void)
 	struct batched_entropy *batch;
 	static void *previous;
-	if (arch_get_random_int(&ret))
-		return ret;
 	batch = raw_cpu_ptr(&batched_entropy_u32);

             reply	other threads:[~2020-02-16 16:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-16 16:18 Jason A. Donenfeld [this message]
2020-02-16 18:23 ` Greg Kroah-Hartman
2020-02-20 22:20   ` Tony Luck
2020-02-20 22:29     ` Tony Luck
2020-02-21 20:08       ` Jason A. Donenfeld
2020-02-22  0:41         ` Theodore Y. Ts'o
2020-02-22  9:59           ` Jason A. Donenfeld
2020-02-24 20:41           ` Luck, Tony
2020-02-21 20:07     ` Jason A. Donenfeld
2020-02-21 20:10       ` [PATCH v2] " Jason A. Donenfeld
2020-02-28  4:09         ` Theodore Y. Ts'o
2020-04-01 13:08         ` Nicolai Stange

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [PATCH] random: always use batched entropy for get_random_u{32,64}' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).