summaryrefslogtreecommitdiff
path: root/lib/Kconfig.debug
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2026-02-23 22:18:48 +0300
committerSasha Levin <sashal@kernel.org>2026-03-04 15:20:54 +0300
commita02cc485d2c7b64d5f643696faa262c1747034ef (patch)
tree14f7bd7f5d6437f64ff97232dd537064fe89d5cb /lib/Kconfig.debug
parent379aac7ee8240848aa35f605b06addb4617c863e (diff)
downloadlinux-a02cc485d2c7b64d5f643696faa262c1747034ef.tar.xz
Remove WARN_ALL_UNSEEDED_RANDOM kernel config option
[ Upstream commit 7dff99b354601dd01829e1511711846e04340a69 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'lib/Kconfig.debug')
-rw-r--r--lib/Kconfig.debug27
1 files changed, 0 insertions, 27 deletions
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index cda3cf1fa302..4bae3b389a9c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1687,33 +1687,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