Re: StackProtector Oopses - Re: 2.6.25-mm1

[Arjan van de Ven]

On Mon, 21 Apr 2008 17:06:04 +0200
Ingo Molnar <mingo@xxxxxxx> wrote:

> 
> * Reuben Farrelly <reuben-linuxkernel@xxxxxxxx> wrote:
> 
> >> hm, does it boot up fine with the attached patch and
> >> stackprotector enabled? It appears that your system got to the
> >> self-test so stackprotector is working mostly - it's just that the
> >> self-test went wrong.
> >
> > It boots up fine with that patch below and:
> >
> > tornado boot # grep STACKPROTECT /boot/config-2.6.25-mm1-wip
> > CONFIG_CC_STACKPROTECTOR_ALL=y
> > CONFIG_CC_STACKPROTECTOR=y
> >
> > In fact I'm running with it applied right now and it all seems good
> > so far, so I guess that's confirmation that it is just the test
> > itself which is problematic?
> 
> yeah. Arjan - any new patches to try that might fix the bootup test?
>

I've looked at the disassembly and compared it to mine, and the gcc is doing
something... rather unexpected.
The only thing I can think of is the patch below, it should make it a ton 
more robust...


From: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
Subject: x86: be more conversative about the stack-protector test

This patch makes the stack-protector self-test more robust against
weird stack layouts; rather than assuming that a local variable is
layed out in a certain way, we first check this against the known
canary value (before we poison it).

Signed-off-by: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>

diff --git a/kernel/panic.c b/kernel/panic.c
index c92c1e2..b4a6a05 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -351,7 +351,10 @@ static noinline void __stack_chk_test_func(void)
 	}
 #endif
 	barrier();
-	memset(&foo, 0, 2*sizeof(foo)); /* deliberate buffer overflow */
+	if (current->stack_canary == *(((unsigned long *)&foo)+1))
+		*(((unsigned long *)&foo)+1) = 0;
+	else
+		printk(KERN_ERR "No -ftack-protector canary found\n");
 	barrier();
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/