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

VDA
2001-07-03T09:24:29Z

On Fri, May 25, 2001 at 07:52:02AM -0400, Brian Gerst wrote:
> 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.

You're talking about something like this?

0.............|taskstruct|guardpage(s)|stack space............FFFFFFFF
^^^^^^^^^^^^ ^^^^^^^^^^^^
This is not these cause
a stack space a page fault
-> double fault
thru task gate

I don't see why task struct have to be moved elsewhere. A couple of
(not-present) pages and some support from MM subsystem is needed as
well as double fault handling code.

> 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.

It could be useful as a debug feature for testing experimental kernels
(selectable by make config).

Pls CC me. I'm not on the list
--
vda@port.imtp.ilyichevsk.odessa.ua