random: check for signal and try earlier when generating entropy
authorJason A. Donenfeld <Jason@zx2c4.com>
Tue, 8 Mar 2022 17:12:16 +0000 (10:12 -0700)
committerJason A. Donenfeld <Jason@zx2c4.com>
Sun, 13 Mar 2022 03:51:39 +0000 (20:51 -0700)
commit3e504d2026eb6c8762cd6040ae57db166516824a
tree7cd0e241000615b841b9be8837032dd1f45bac6c
parent7a7ff644aeaf071d433caffb3b8ea57354b55bd3
random: check for signal and try earlier when generating entropy

Rather than waiting a full second in an interruptable waiter before
trying to generate entropy, try to generate entropy first and wait
second. While waiting one second might give an extra second for getting
entropy from elsewhere, we're already pretty late in the init process
here, and whatever else is generating entropy will still continue to
contribute. This has implications on signal handling: we call
try_to_generate_entropy() from wait_for_random_bytes(), and
wait_for_random_bytes() always uses wait_event_interruptible_timeout()
when waiting, since it's called by userspace code in restartable
contexts, where signals can pend. Since try_to_generate_entropy() now
runs first, if a signal is pending, it's necessary for
try_to_generate_entropy() to check for signals, since it won't hit the
wait until after try_to_generate_entropy() has returned. And even before
this change, when entering a busy loop in try_to_generate_entropy(), we
should have been checking to see if any signals are pending, so that a
process doesn't get stuck in that loop longer than expected.

Cc: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
drivers/char/random.c