Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751224AbdFBRlP (ORCPT ); Fri, 2 Jun 2017 13:41:15 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:34071 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751141AbdFBRlN (ORCPT ); Fri, 2 Jun 2017 13:41:13 -0400 Message-ID: <1496425271.1989.1.camel@gmail.com> Subject: Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete From: Daniel Micay To: "Jason A. Donenfeld" , Stephan Mueller , "Theodore Ts'o" , Linux Crypto Mailing List , LKML , kernel-hardening@lists.openwall.com Date: Fri, 02 Jun 2017 13:41:11 -0400 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1677 Lines: 51 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.