Re: [PATCH] random: seed random_int_secret at least poorly at core_initcall time

On Fri, Nov 15, 2013 at 10:42:28AM -0800, Kees Cook wrote:

On Wed, Nov 13, 2013 at 8:18 PM, Hannes Frederic Sowa
[off-list ref] wrote:

quoted

On Wed, Nov 13, 2013 at 09:54:48PM -0500, Theodore Ts'o wrote:

quoted

On Tue, Nov 12, 2013 at 02:46:03PM +0100, Hannes Frederic Sowa wrote:

quoted

quoted

It is needed by fork to set up the stack canary. And this actually gets
called before the secret is initialized.

Maybe we could use this for the time being and use the seeding method
of kaslr as soon as it hits the tree?

Hmm, from what I can tell even early_initcall() is going to be early
enough.  The stack canary is set up by boot_init_stack_canary(), which
is run very, very early in start_kerne() --- way before
early_initcalls, or even before interrupts are enabled.  So adding
random_int_secret_init_early() as a core_initcall is still too late.

Actually I tried to protect the tsk->stack_canary = get_random_int()
in fork.c. It sets up the per-task canary.

I haven't looked closely yet at how the stack canary gets plumbed, but
what do things outside of process context end up using?

Early on boot __stack_chk_guard gets initialized. The address of this symbol
is looked up by gcc to assemble the stack guard checks.

Only on ARM with !CONFIG_SMP the __stack_chk_guard is switched as soon
as a new process context is entered. This is not possible if the kernel
is compiled for CONFIG_SMP and the kernel will fallback to the one global
__stack_chk_guard canary.

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html