linux-kernel - Re: get_random_bytes returns bad randomness before seeding is complete

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 2 Jun 2017 17:53:39 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Stephan Mueller <smueller@...onox.de>,
        "Theodore Ts'o" <tytso@....edu>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-hardening@...ts.openwall.com
Subject: Re: get_random_bytes returns bad randomness before seeding is complete

(Meanwhile...)

In my own code, I'm currently playing with a workaround that looks like this:

--- a/src/main.c
+++ b/src/main.c

+#include <linux/completion.h>
+#include <linux/random.h>

+struct rng_initializer {
+       struct completion done;
+       struct random_ready_callback cb;
+};
+static void rng_initialized_callback(struct random_ready_callback *cb)
+{
+       complete(&container_of(cb, struct rng_initializer, cb)->done);
+}
+
static int __init mod_init(void)
{
       int ret;
+       struct rng_initializer rng = {
+               .done = COMPLETION_INITIALIZER(rng.done),
+               .cb = { .owner = THIS_MODULE, .func = rng_initialized_callback }
+       };
+
+       ret = add_random_ready_callback(&rng.cb);
+       if (!ret)
+               wait_for_completion(&rng.done);
+       else if (ret != -EALREADY)
+               return ret;

       do_things_with_get_random_bytes_maybe();

Depending on the situation, however, I could imagine that
wait_for_completion never returning, if its blocking activity that
contributes to the seed actually being available, if this is called
from a compiled-in module, so I find this a bit sub-optimal...