[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jLXMsM1rGzK7hot7qWOWJNW5V_NnCks1YZ3SKhCoHZxjg@mail.gmail.com>
Date: Fri, 2 Jun 2017 11:58:25 -0700
From: Kees Cook <keescook@...omium.org>
To: Daniel Micay <danielmicay@...il.com>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>, 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" <kernel-hardening@...ts.openwall.com>
Subject: Re: Re: get_random_bytes returns bad randomness
before seeding is complete
On Fri, Jun 2, 2017 at 10:41 AM, Daniel Micay <danielmicay@...il.com> wrote:
> On Fri, 2017-06-02 at 17:53 +0200, Jason A. Donenfeld wrote:
>> (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...
>
> One of the early uses is initializing the stack canary value for SSP in
> very early boot. If that blocks, it's going to be blocking nearly
> anything else from happening.
>
> On x86, that's only the initial canary since the per-task canaries end
> up being used, but elsewhere at least without SMP disabled or changes to
> GCC that's all there is so the entropy matters.
And just to note, building with GCC_PLUGIN_LATENT_ENTROPY, while it
(correctly) doesn't credit entropy to the pool, should at least make
the pool less deterministic between boots.
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
