Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751202AbdFBRqt (ORCPT ); Fri, 2 Jun 2017 13:46:49 -0400 Received: from frisell.zx2c4.com ([192.95.5.64]:58193 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751141AbdFBRqr (ORCPT ); Fri, 2 Jun 2017 13:46:47 -0400 MIME-Version: 1.0 In-Reply-To: <1496425271.1989.1.camel@gmail.com> References: <1496425271.1989.1.camel@gmail.com> From: "Jason A. Donenfeld" Date: Fri, 2 Jun 2017 19:46:43 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete To: Daniel Micay Cc: 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: 748 Lines: 14 On Fri, Jun 2, 2017 at 7:41 PM, Daniel Micay wrote: > 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. If this is the case, then we simply need a function called get_random_bytes_but_potentially_crappy_ones_because_we_are_desperate_for_anything(), which would respond with a weaker guarantee than that get_random_bytes(), which the documentation says always returns cryptographically secure numbers.