Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jun 2016 08:50:38 -0700
From: Kees Cook <>
To: David Brown <>
Cc: "" <>, 
	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 <>,, 
	"David S. Miller" <>
Subject: Re: Re: [PATCH v2 1/3] Add the latent_entropy gcc plugin

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 Cook
Chrome OS & Brillo Security

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.