On Mon, Sep 26, 2022 at 6:22 PM Andrew Morton akpm@linux-foundation.org wrote:
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.
Sure. I'll expand that paragraph to read:
This ensures that, for example, slabs are properly randomized if RDRAND is available. Without this, CONFIG_SLAB_FREELIST_RANDOM=y loses a degree of its security, because its random seed is potentially deterministic, since it hasn't yet incorporated RDRAND. It also makes it possible to use a better seed in kfence, which currently relies on only the cycle counter. Another positive consequence is that on systems with RDRAND, running with CONFIG_WARN_ALL_UNSEEDED_RANDOM=y results in no warnings at all.