random: do not xor RDRAND when writing into /dev/random

Continuing the reasoning of "random: ensure early RDSEED goes through
mixer on init", we don't want RDRAND interacting with anything without
going through the mixer function, as a backdoored CPU could presumably
cancel out data during an xor, which it'd have a harder time doing when
being forced through a cryptographic hash function. There's actually no
need at all to be calling RDRAND in write_pool(), because before we
extract from the pool, we always do so with 32 bytes of RDSEED hashed in
at that stage. Xoring at this stage is needless and introduces a minor
liability.

Cc: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 21a067c..d31b0b3 100644 (file)
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1305,25 +1305,15 @@ static __poll_t random_poll(struct file *file, poll_table *wait)
 static int write_pool(const char __user *buffer, size_t count)
 {
        size_t bytes;
-       u32 t, buf[16];
+       u8 buf[BLAKE2S_BLOCK_SIZE];
        const char __user *p = buffer;
 
        while (count > 0) {
-               int b, i = 0;
-
                bytes = min(count, sizeof(buf));
-               if (copy_from_user(&buf, p, bytes))
+               if (copy_from_user(buf, p, bytes))
                        return -EFAULT;
-
-               for (b = bytes; b > 0; b -= sizeof(u32), i++) {
-                       if (!arch_get_random_int(&t))
-                               break;
-                       buf[i] ^= t;
-               }
-
                count -= bytes;
                p += bytes;
-
                mix_pool_bytes(buf, bytes);
                cond_resched();
        }