From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752237AbcEYCzW (ORCPT ); Tue, 24 May 2016 22:55:22 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:38691 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751148AbcEYCzU (ORCPT ); Tue, 24 May 2016 22:55:20 -0400 MIME-Version: 1.0 In-Reply-To: <5744E665.28844.9DDA03D@pageexec.freemail.hu> References: <20160524001405.3e6abd1d5a63a871cc366cff@gmail.com> <20160524001529.0e69232eff0b1b5bc566a763@gmail.com> <5744E665.28844.9DDA03D@pageexec.freemail.hu> From: Kees Cook Date: Tue, 24 May 2016 19:55:17 -0700 X-Google-Sender-Auth: -69kY1qoSDN-7EtbxOAMtf6VTJA Message-ID: Subject: Re: [PATCH v1 1/3] Add the latent_entropy gcc plugin To: PaX Team Cc: Emese Revfy , "kernel-hardening@lists.openwall.com" , Brad Spengler , Michal Marek , LKML , Masahiro Yamada , linux-kbuild , "Theodore Ts'o" , Andrew Morton , Linux-MM , Jens Axboe , Al Viro , Paul McKenney , Ingo Molnar , Thomas Gleixner , bart.vanassche@sandisk.com, "David S. Miller" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 24, 2016 at 4:40 PM, PaX Team wrote: > On 24 May 2016 at 10:32, Kees Cook wrote: > >> On Mon, May 23, 2016 at 3:15 PM, Emese Revfy wrote: >> > This plugin mitigates the problem of the kernel having too little entropy during >> > and after boot for generating crypto keys. >> > >> I'm excited to see this! This looks like it'll help a lot with early >> entropy, which is something that'll be a problem for some >> architectures that are trying to do early randomish things (e.g. the >> heap layout randomization, various canaries, etc). >> >> Do you have any good examples of a before/after case of early >> randomness being fixed by this? > > unfortunately, i don't know of a way to quantify this kind of PRNG as the effective > algorithm is not something simple and well-structured for which we have theories and > tools to analyze already. of course this cuts both ways, an attacker faces the same > barrier of non-analyzability. > > what can at most be observed is the state of the latent_entropy global variable after > init across many boots but that'd provide a rather low and useless lower estimate only > (e.g., up to 20 bits for a million reboots, or 30 bits for a billion reboots, etc). > > to answer your question, i'd like to believe that there's enough latent entropy in > program state that can be harnessed to (re)seed the entropy pool but we'll probably > never know just how well we are doing it so accounting for it and claiming 'fixed' > will stay in the realm of wishful thinking i'm afraid. Yeah, answering "how random is this?" is not easy, but that's not what I meant. I'm more curious about specific build configs or hardware where calling get_random_int() early enough would always produce the same value (or the same value across all threads, etc), and in these cases, the new entropy should be visible when using the latent entropy plugin. -Kees -- Kees Cook Chrome OS & Brillo Security