From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
kernel-hardening@lists.openwall.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: [PATCH RFC v2 3/8] random: warn when kernel uses unseeded randomness
Date: Mon, 5 Jun 2017 05:47:52 +0200 [thread overview]
Message-ID: <20170605034757.4803-4-Jason@zx2c4.com> (raw)
In-Reply-To: <20170605034757.4803-1-Jason@zx2c4.com>
This enables an important dmesg notification about when drivers have
used the crng without it being seeded first. Prior, these errors would
occur silently, and so there hasn't been a great way of diagnosing these
types of bugs for obscure setups. By adding this as a config option, we
can leave it on by default, so that we learn where these issues happen,
in the field, will still allowing some people to turn it off, if they
really know what they're doing and do not want the log entries.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
drivers/char/random.c | 3 +--
lib/Kconfig.debug | 15 +++++++++++++++
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 035a5d7c06bd..9320b04235ae 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -285,7 +285,6 @@
#define SEC_XFER_SIZE 512
#define EXTRACT_SIZE 10
-#define DEBUG_RANDOM_BOOT 0
#define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))
@@ -1470,7 +1469,7 @@ void get_random_bytes(void *buf, int nbytes)
{
__u8 tmp[CHACHA20_BLOCK_SIZE];
-#if DEBUG_RANDOM_BOOT > 0
+#ifdef CONFIG_WARN_UNSEEDED_RANDOM
if (!crng_ready())
printk(KERN_NOTICE "random: %pF get_random_bytes called "
"with crng_init = %d\n", (void *) _RET_IP_, crng_init);
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e4587ebe52c7..fd5e67bcd46c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1209,6 +1209,21 @@ config STACKTRACE
It is also used by various kernel debugging features that require
stack trace generation.
+config WARN_UNSEEDED_RANDOM
+ bool "Warn when kernel uses unseeded randomness"
+ default y
+ 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.
+
+ Say Y here, unless you simply do not care about using unseeded
+ randomness and do not want a potential warning message in your logs.
+
config DEBUG_KOBJECT
bool "kobject debugging"
depends on DEBUG_KERNEL
--
2.13.0
next prev parent reply other threads:[~2017-06-05 3:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-05 3:47 [PATCH RFC v2 0/8] get_random_bytes_wait family of APIs Jason A. Donenfeld
2017-06-05 3:47 ` [PATCH RFC v2 1/8] random: add synchronous API for the urandom pool Jason A. Donenfeld
2017-06-05 3:47 ` [PATCH RFC v2 2/8] random: add get_random_{bytes,u32,u64,int,long,once}_wait family Jason A. Donenfeld
2017-06-05 3:47 ` Jason A. Donenfeld [this message]
2017-06-05 3:47 ` [PATCH RFC v2 4/8] crypto/rng: ensure that the RNG is ready before using Jason A. Donenfeld
2017-06-05 3:47 ` [PATCH RFC v2 5/8] security/keys: ensure RNG is seeded before use Jason A. Donenfeld
2017-06-05 23:18 ` Jason A. Donenfeld
2017-06-05 3:47 ` [PATCH RFC v2 6/8] iscsi: " Jason A. Donenfeld
2017-06-05 3:47 ` [PATCH RFC v2 7/8] bluetooth/smp: ensure RNG is properly seeded before ECDH use Jason A. Donenfeld
2017-06-05 3:47 ` [PATCH RFC v2 8/8] ceph: ensure RNG is seeded before using Jason A. Donenfeld
2017-06-05 23:47 ` [PATCH RFC v2 0/8] get_random_bytes_wait family of APIs Jason A. Donenfeld
2017-06-06 7:45 ` Greg Kroah-Hartman
2017-06-06 12:24 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170605034757.4803-4-Jason@zx2c4.com \
--to=jason@zx2c4.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox