From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752470AbcFFPum (ORCPT ); Mon, 6 Jun 2016 11:50:42 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:36819 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751160AbcFFPuk (ORCPT ); Mon, 6 Jun 2016 11:50:40 -0400 MIME-Version: 1.0 In-Reply-To: <20160606133801.GA6136@davidb.org> References: <20160531013029.4c5db8b570d86527b0b53fe4@gmail.com> <20160531013145.612696c12f2ef744af739803@gmail.com> <20160601124227.e922af8299168c09308d5e1b@linux-foundation.org> <20160603194252.91064b8e682ad988283fc569@gmail.com> <20160606133801.GA6136@davidb.org> From: Kees Cook Date: Mon, 6 Jun 2016 08:50:38 -0700 X-Google-Sender-Auth: ShsIPUqIm6xIr4PGiNHpbirdPkk Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v2 1/3] Add the latent_entropy gcc plugin To: David Brown Cc: "kernel-hardening@lists.openwall.com" , Andrew Morton , PaX Team , Brad Spengler , Michal Marek , LKML , Masahiro Yamada , linux-kbuild , "Theodore Ts'o" , 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 Mon, Jun 6, 2016 at 6:38 AM, David Brown wrote: > On Fri, Jun 03, 2016 at 07:42:52PM +0200, Emese Revfy wrote: >> >> On Wed, 1 Jun 2016 12:42:27 -0700 >> Andrew Morton wrote: >> >>> On Tue, 31 May 2016 01:31:45 +0200 Emese Revfy >>> wrote: >>> >>> > This plugin mitigates the problem of the kernel having too little >>> > entropy during >>> > and after boot for generating crypto keys. >>> > >>> > It creates a local variable in every marked function. The value of this >>> > variable is >>> > modified by randomly chosen operations (add, xor and rol) and >>> > random values (gcc generates them at compile time and the stack pointer >>> > at runtime). >>> > It depends on the control flow (e.g., loops, conditions). >>> > >>> > Before the function returns the plugin writes this local variable >>> > into the latent_entropy global variable. The value of this global >>> > variable is >>> > added to the kernel entropy pool in do_one_initcall() and _do_fork(). >>> >>> I don't think I'm really understanding. Won't this produce the same >>> value on each and every boot? >> >> >> No, because of interrupts and intentional data races. > > > Wouldn't that result in the value having one of a small number of > values, then? Even if it was just one of thousands or millions of > values, it would make the search space quite small. My understanding is that it's not cryptographically secure, but it provides a way for different machines and different boots to end up with different seeds here, which is a big improvement over some of the embedded devices that all boot with the same entropy every time. I would, however, like to see the documentation improved to describe the "How" and "Why". The "What" is pretty well covered. Adding comments to the plugin for kernel developers (not compiler developers) would help a lot: assume the reader knows nothing about gcc plugins. :) -Kees -- Kees Cook Chrome OS & Brillo Security