summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2020-02-21 21:10:37 +0100
committerBen Hutchings <ben@decadent.org.uk>2020-06-11 19:05:58 +0100
commit493b4e7e4ed9cb671788d886bbc0f8d26ae10dba (patch)
treeae7b823a387f99539a2c7faae538b859d31fe33a
parent948cfe9d8a2e3f0465340d5dea9d61f282df00e7 (diff)
downloadlinux-stable-493b4e7e4ed9cb671788d886bbc0f8d26ae10dba.tar.gz
linux-stable-493b4e7e4ed9cb671788d886bbc0f8d26ae10dba.tar.bz2
linux-stable-493b4e7e4ed9cb671788d886bbc0f8d26ae10dba.zip
random: always use batched entropy for get_random_u{32,64}
commit 69efea712f5b0489e67d07565aad5c94e09a3e52 upstream. It turns out that RDRAND is pretty slow. Comparing these two constructions: for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret)) arch_get_random_long(&ret); and 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 <Jason@zx2c4.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20200221201037.30231-1-Jason@zx2c4.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.16: Only get_random_int() exists here] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
-rw-r--r--drivers/char/random.c3
1 files changed, 0 insertions, 3 deletions
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 0787fa2bdf27..4fd33598ce0a 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1700,9 +1700,6 @@ unsigned int get_random_int(void)
__u32 *hash;
unsigned int ret;
- if (arch_get_random_int(&ret))
- return ret;
-
hash = get_cpu_var(get_random_int_hash);
hash[0] += current->pid + jiffies + random_get_entropy();