[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 16 Jun 2016 23:42:55 -0400
From: Sandy Harris <sandyinchina@...il.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: Initialising random(4)
Kees Cook <keescook@...omium.org> wrote:
>>> Right now, the
>>> latent_entropy plugin does some static initialization with build-time
>>> randomness, and then augments the pool with additional entropy during
>>> boot. How does yours differ?
>>
>> Mine initialises all pools at compile time, using data from
>> /dev/urandom on the development machine
>
> Cool. Based on my quick examination, I think the latent_entropy way of
> doing this is no less secure but is much easier to implement (it's
> just an attribute addition in the code). It looks like your version
> ends up with a lot of #ifdefs, etc, and targets a single collection of
> arrays.
The #ifdefs are just because this was an RFC test version so
I used a CONFIG variable to control whether my initialisation
was done. Turn it off & the pool arrays just get declared.
If the patch were accepted, no #ifdefs would be needed.
> I'm open to ways these two methods could work together, of course!
I have not looked closely at the latent-entropy plug in. One
option would be to use my stuff at build time and the
other at boot time.
There were other parts of my patch series intended to
help at boot time, but unlike the initialisation stuff they
were somewhat complex and part of an all-or-nothing
proposed rewrite of a large chunk of the driver. Also,
unlike the init stuff they would not apply to the current
driver because Ted has changed some things since
I did those patches.
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.
