On Mon, 26 Sep 2022 18:03:32 +0200 "Jason A. Donenfeld" <Jason@xxxxxxxxx> 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@xxxxxxxxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > Cc: stable@xxxxxxxxxxxxxxx Which is important when proposing a -stable backport.