summaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2026-02-23 11:18:48 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2026-02-23 11:18:48 -0800
commit7dff99b354601dd01829e1511711846e04340a69 (patch)
tree3d3c73964e6ec40d6ff69ef4dffd9b975da2b2d1 /lib
parent551d44200152cb26f75d2ef990aeb6185b7e37fd (diff)
Remove WARN_ALL_UNSEEDED_RANDOM kernel config optionHEADmaster
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. Fixes: cc1e127bfa95 ("random: remove ratelimiting for in-kernel unseeded randomness") Acked-by: Jason Donenfeld <Jason@zx2c4.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'lib')
-rw-r--r--lib/Kconfig.debug27
1 files changed, 0 insertions, 27 deletions
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 4e2dfbbd3d78..318df4c75454 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1766,33 +1766,6 @@ config STACKTRACE
It is also used by various kernel debugging features that require
stack trace generation.
-config WARN_ALL_UNSEEDED_RANDOM
- bool "Warn for all uses of unseeded randomness"
- default n
- help
- Some parts of the kernel contain bugs relating to their use of
- cryptographically secure random numbers before it's actually possible
- to generate those numbers securely. This setting ensures that these
- flaws don't go unnoticed, by enabling a message, should this ever
- occur. This will allow people with obscure setups to know when things
- are going wrong, so that they might contact developers about fixing
- it.
-
- Unfortunately, on some models of some architectures getting
- a fully seeded CRNG is extremely difficult, and so this can
- result in dmesg getting spammed for a surprisingly long
- time. This is really bad from a security perspective, and
- so architecture maintainers really need to do what they can
- to get the CRNG seeded sooner after the system is booted.
- However, since users cannot do anything actionable to
- address this, by default this option is disabled.
-
- Say Y here if you want to receive warnings for all uses of
- unseeded randomness. This will be of use primarily for
- those developers interested in improving the security of
- Linux kernels running on their architecture (or
- subarchitecture).
-
config DEBUG_KOBJECT
bool "kobject debugging"
depends on DEBUG_KERNEL