Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751244AbdFBS63 (ORCPT ); Fri, 2 Jun 2017 14:58:29 -0400 Received: from mail-it0-f54.google.com ([209.85.214.54]:36640 "EHLO mail-it0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751007AbdFBS61 (ORCPT ); Fri, 2 Jun 2017 14:58:27 -0400 MIME-Version: 1.0 In-Reply-To: <1496425271.1989.1.camel@gmail.com> References: <1496425271.1989.1.camel@gmail.com> From: Kees Cook Date: Fri, 2 Jun 2017 11:58:25 -0700 X-Google-Sender-Auth: ncMcXm9w-j2BYQW65kBMI03mxPQ Message-ID: Subject: Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete To: Daniel Micay Cc: "Jason A. Donenfeld" , Stephan Mueller , "Theodore Ts'o" , Linux Crypto Mailing List , LKML , "kernel-hardening@lists.openwall.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2024 Lines: 62 On Fri, Jun 2, 2017 at 10:41 AM, Daniel Micay 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 >> +#include >> >> +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