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 wonder if we need to do something in common with what Kees has been > considering for the kaslr code, since it's a similar issue --- we need > random number way earlier than we can really afford to initialize > /dev/random. Definiteley. I would also propose hashing the boot arguments, often enough there is a filesystem UUID in there, or even hash the multiboot information we are given from grub. Maybe compile-time entropy, at least a bit. > P.S. Unless I'm missing something (and I hope I am), it would appear > that the stack canary is going to easily predictable by an attacker on > non-x86 platforms that don't have RDRAND. Has someone tested whether > or not the stack canary isn't constant across ARM or pre-Sandy Bridge > x86 systems? In case of protection for interrupt stacks and early cmwq threads, it looks pretty bad from a first look at the source (at least for the first initialized CPU). I'll try to do some tests tomorrow. Greetings, Hannes -- 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
