On Mon, 26 Sep 2022 18:03:32 +0200 "Jason A. Donenfeld" Jason@zx2c4.com wrote:
The full RNG initialization relies on some timestamps, made possible with general functions like time_init() and timekeeping_init(). However, these are only available rather late in initialization. Meanwhile, other things, such as memory allocator functions, make use of the RNG much earlier.
So split RNG initialization into two phases. We can give arch randomness very early on, and then later, after timekeeping and such are available, initialize the rest.
This ensures that, for example, slabs are properly randomized if RDRAND is available. Another positive consequence is that on systems with RDRAND, running with CONFIG_WARN_ALL_UNSEEDED_RANDOM=y results in no warnings at all.
Please give a full description of the user-visible runtime effects of this shortcoming.
Cc: Kees Cook keescook@chromium.org Cc: Andrew Morton akpm@linux-foundation.org Cc: stable@vger.kernel.org
Which is important when proposing a -stable backport.