Re: [CHECKER] large stack variables (>=1K) in 2.4.4 and 2.4.4-ac8

[Brian Gerst]

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