random: use a different mixing algorithm for add_device_randomness()
authorTheodore Ts'o <tytso@mit.edu>
Wed, 11 Apr 2018 18:58:27 +0000 (14:58 -0400)
committerTheodore Ts'o <tytso@mit.edu>
Sat, 14 Apr 2018 15:59:09 +0000 (11:59 -0400)
commitdc12baacb95f205948f64dc936a47d89ee110117
tree1e2e7e65b48e21064e337dae6f4e4a93fa7ce54a
parent43838a23a05fbd13e47d750d3dfd77001536dd33
random: use a different mixing algorithm for add_device_randomness()

add_device_randomness() use of crng_fast_load() was highly
problematic.  Some callers of add_device_randomness() can pass in a
large amount of static information.  This would immediately promote
the crng_init state from 0 to 1, without really doing much to
initialize the primary_crng's internal state with something even
vaguely unpredictable.

Since we don't have the speed constraints of add_interrupt_randomness(),
we can do a better job mixing in the what unpredictability a device
driver or architecture maintainer might see fit to give us, and do it
in a way which does not bump the crng_init_cnt variable.

Also, since add_device_randomness() doesn't bump any entropy
accounting in crng_init state 0, mix the device randomness into the
input_pool entropy pool as well.  This is related to CVE-2018-1108.

Reported-by: Jann Horn <jannh@google.com>
Fixes: ee7998c50c26 ("random: do not ignore early device randomness")
Cc: stable@kernel.org # 4.13+
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
drivers/char/random.c