Messages in this thread |  | | Date | Fri, 25 May 2001 07:52:02 -0400 | From | Brian Gerst <> | Subject | Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |