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 > <hannes@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Nov 13, 2013 at 09:54:48PM -0500, Theodore Ts'o wrote: > >> On Tue, Nov 12, 2013 at 02:46:03PM +0100, Hannes Frederic Sowa wrote: > >> > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
