From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 25 May 2001 07:52:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 25 May 2001 07:52:13 -0400 Received: from femail18.sdc1.sfba.home.com ([24.0.95.145]:43140 "EHLO femail18.sdc1.sfba.home.com") by vger.kernel.org with ESMTP id ; Fri, 25 May 2001 07:52:02 -0400 Message-ID: <3B0E4762.7A7A3818@didntduck.org> Date: Fri, 25 May 2001 07:52:02 -0400 From: Brian Gerst X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.5-pre3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Andi Kleen CC: Linux kernel mailing list Subject: Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8 In-Reply-To: <200105242110.OAA29766@csl.Stanford.EDU> <200105242308.f4ON8fv8015978@webber.adilger.int> <20010525013303.A21810@gruyere.muc.suse.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andi Kleen wrote: > > On Thu, May 24, 2001 at 05:08:40PM -0600, Andreas Dilger wrote: > > I'm curious about this stack checker. Does it check for a single > > stack allocation >= 1024 bytes, or does it also check for several > > individual, smaller allocations which total >= 1024 bytes inside > > a single function? That would be equally useful. > > At one time someone had a script to grep objdump -S vmlinux for the > stack allocations generated by gcc and check them. It found a few > cases. It is easy to rewrite, as they are very regular instruction > patterns at the beginning of functions (at least when you ignore variable > length stack arrays, which do not seem to be common in the kernel anyways) > > > > > On a side note, does anyone know if the kernel does checking if the > > stack overflowed at any time? It is hard to use Dawson's tools to > > verify call paths because of interrupts and such, but I wonder what > > happens when the kernel stack overflows - OOPS, or silent corruption? > > You normally get a silent hang or worse a stack fault exception > (which linux/x86 without kdb cannot recover from) which gives you instant > reboot. > The ikd patches contain a stack overflow checker for runtime. Actually, you will never get a stack fault exception, since with a flat stack segment you can never get a limit violation. All you will do is corrupt the data in task struct and cause an oops later on when the kernel tries to use the task struct. There are only two ways to properly trap a kernel stack overflow: - Make the stack segment non-flat, putting the limit just above the task struct. Ugly, because we want to stay away from segmentation. The stack fault handler would have to be a task gate. This also causes problems because pointers accessed through %ebp also use the stack segment by default. We would either need to leave frame pointers turned on or teach GCC to use %ds overrides when using %ebp as a pointer. - Add a not-present guard page at the bottom of the stack. This means the stack would have to live in vmalloc'ed memory, which I don't think the kernel can handle at this time (with lazy vmalloc mapping). The task struct would have to be moved elsewhere or it would still get overwritten. Then a double fault task would be able to detect this and kill the task. In other words, with the current x86 architecture, there isn't really much we can do to handle stack overflows without sacrificing performance. Good discipline is the best we have. -- Brian Gerst