linux-kernel - Re: StackProtector Oopses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080421184859.48efcb67@laptopd505.fenrus.org>
Date:	Mon, 21 Apr 2008 18:48:59 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Reuben Farrelly <reuben-linuxkernel@...b.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: StackProtector Oopses - Re: 2.6.25-mm1

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

> 
> * Reuben Farrelly <reuben-linuxkernel@...b.net> 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@...ux.intel.com>
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@...ux.intel.com>

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/