[kernel-hardening] Initialising random(4)

[kernel-hardening] Initialising random(4)

[Sandy Harris]

The gresecurity patches include code to initiailse the driver's pools
with random data. I have different code to accomplish the same task &
think anyone planning to integrate that part of the gre stuff into the
kernel should also have a look at mine:
https://github.com/sandy-harris/random.gcm/blob/random_gcm/scripts/gen_random.c

I submitted an earlier version as a kernel patch, part of a large &
complex series of proposed patches.

Re: [kernel-hardening] Initialising random(4)

[Kees Cook]

On Thu, Jun 16, 2016 at 10:06 AM, Sandy Harris <sandyinchina@gmail.com> wrote:
> The gresecurity patches include code to initiailse the driver's pools
> with random data. I have different code to accomplish the same task &
> think anyone planning to integrate that part of the gre stuff into the
> kernel should also have a look at mine:
> https://github.com/sandy-harris/random.gcm/blob/random_gcm/scripts/gen_random.c
>
> I submitted an earlier version as a kernel patch, part of a large &
> complex series of proposed patches.

Do you have a URL to the kernel patch you sent? 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?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Initialising random(4)

[Sandy Harris]

On Thu, Jun 16, 2016 at 1:10 PM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, Jun 16, 2016 at 10:06 AM, Sandy Harris <sandyinchina@gmail.com> wrote:

>> The gresecurity patches include code to initiailse the driver's pools
>> with random data. I have different code to accomplish the same task &
>> think anyone planning to integrate that part of the gre stuff into the
>> kernel should also have a look at mine:
>> https://github.com/sandy-harris/random.gcm/blob/random_gcm/scripts/gen_random.c
>>
>> I submitted an earlier version as a kernel patch, part of a large &
>> complex series of proposed patches.
>
> Do you have a URL to the kernel patch you sent?

Create the program to initialise things:
https://lkml.org/lkml/2015/11/7/137

Changes to the driver to use it:
https://lkml.org/lkml/2015/11/7/133

> 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

Re: [kernel-hardening] Initialising random(4)

[Kees Cook]

On Thu, Jun 16, 2016 at 10:31 AM, Sandy Harris <sandyinchina@gmail.com> wrote:
> On Thu, Jun 16, 2016 at 1:10 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Thu, Jun 16, 2016 at 10:06 AM, Sandy Harris <sandyinchina@gmail.com> wrote:
>
>>> The gresecurity patches include code to initiailse the driver's pools
>>> with random data. I have different code to accomplish the same task &
>>> think anyone planning to integrate that part of the gre stuff into the
>>> kernel should also have a look at mine:
>>> https://github.com/sandy-harris/random.gcm/blob/random_gcm/scripts/gen_random.c
>>>
>>> I submitted an earlier version as a kernel patch, part of a large &
>>> complex series of proposed patches.
>>
>> Do you have a URL to the kernel patch you sent?
>
> Create the program to initialise things:
> https://lkml.org/lkml/2015/11/7/137
>
> Changes to the driver to use it:
> https://lkml.org/lkml/2015/11/7/133

Okay, thanks for the pointers. Yeah, this looks similar to what
latent_entropy does.

>> 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.

I'm open to ways these two methods could work together, of course!

Thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Initialising random(4)

[Sandy Harris]

Kees Cook <keescook@chromium.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.