]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
random: invalidate batched entropy after crng init
authorJason A. Donenfeld <Jason@zx2c4.com>
Wed, 7 Jun 2017 23:45:31 +0000 (19:45 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 14 Jun 2017 13:07:44 +0000 (15:07 +0200)
commit86f95e53ed76fec2579e00351c6050ab398a7730
tree1659483ff257759e0db6ad7835ab70e8375d5ee3
parent0524867ee278b8d9efb19e7a9fbae78ae59503b6
random: invalidate batched entropy after crng init

commit b169c13de473a85b3c859bb36216a4cb5f00a54a upstream.

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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/char/random.c