random: invalidate batched entropy after crng init
authorJason A. Donenfeld <Jason@zx2c4.com>
Wed, 7 Jun 2017 23:45:31 +0000 (19:45 -0400)
committerTheodore Ts'o <tytso@mit.edu>
Wed, 7 Jun 2017 23:45:37 +0000 (19:45 -0400)
commitb169c13de473a85b3c859bb36216a4cb5f00a54a
tree4e6078fbf5f50be9fb113087f4affa3d19f1a25a
parent92e75428ffc90e2a0321062379f883f3671cfebe
random: invalidate batched entropy after crng init

It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.

In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
drivers/char/random.c