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