LINUX KERNEL
Following yesterday’s Linux 7.0-rc1 release, Linus Torvalds authored and merged a patch to get rid of the Linux kernel’s WARN_ALL_UNSEEDED_RANDOM Kconfig option. While that option was added with good intentions, on some systems it can yield a lot of unnecessary kernel log spam.

The WARN_ALL_UNSEEDED_RANDOM option has for many years been part of the Linux kernel and enabling it will provide a warning whenever there is a use of unseeded randomness within the kernel. To help spot situations of random number generation use prior to being able to securely use RNG on the system, this option was added long ago to help spot such uses of unseeded randomness by kernel code. But due to caveats on some CPUs around a fully-seeded CRNG, the WARN_ALL_UNSEEDED_RANDOM can become like an endless stream of spam. After encountering a bug report where much of the kernel log were just messages about unseeded randomness and in turn losing some of the initial boot log, Torvalds had enough and gutted out this option.

Linus Torvalds explains in this patch dropping the WARN_ALL_UNSEEDED_RANDOM option:

“This config option goes way back – it used to be an internal debug option to random.c (at that point called DEBUG_RANDOM_BOOT), then was renamed and exposed as a config option as CONFIG_WARN_UNSEEDED_RANDOM, and then further renamed to the current CONFIG_WARN_ALL_UNSEEDED_RANDOM.

It was all done with the best of intentions: the more limited rate-limited reports were reporting some cases, but if you wanted to see all the gory details, you’d enable this “ALL” option.

However, it turns out – perhaps not surprisingly – that when people don’t care about and fix the first rate-limited cases, they most certainly don’t care about any others either, and so warning about all of them isn’t actually helping anything.

And the non-ratelimited reporting causes problems, where well-meaning people enable debug options, but the excessive flood of messages that nobody cares about will hide actual real information when things go wrong.

I just got a kernel bug report (which had nothing to do with randomness) where two thirds of the the truncated dmesg was just variations of

random: get_random_u32 called from __get_random_u32_below+0x10/0x70 with crng_init=0

and in the process early boot messages had been lost (in addition to making the messages that _hadn’t_ been lost harder to read).

The proper way to find these things for the hypothetical developer that cares – if such a person exists – is almost certainly with boot time tracing. That gives you the option to get call graphs etc too, which is likely a requirement for fixing any problems anyway.

See Documentation/trace/boottime-trace.rst for that option.

And if we for some reason do want to re-introduce actual printing of these things, it will need to have some uniqueness filtering rather than this “just print it all” model.”

Makes sense and thankfully these rather annoying kernel log messages will be disappearing with this option removed.

Besides dropping this option today, this weekend prior to tagging Linux 7.0-rc1, Torvalds also did a bit of coding in introducing the default_gfp() helper macro and adapting existing kernel code to make use of it.