Re: Wanted: simple, safe x86 stack overflow detection

[Bill Irwin]

Bill Irwin wrote:
>> Chuck, is any of this of any use to you?

On Tue, Mar 06, 2007 at 01:59:39PM -0500, Chuck Ebbert wrote:
> I said "simple." :)
> In the 4k/4k stack i386 kernel, is there any fundamental reason it
> can't be 4k/8k? We seem to be mostly hitting problems in overflowing
> the IRQ stack... I think. Overhead would only be 4k per CPU for that.

current is derived from current_thread_info()->task which is in turn
derived from the stack pointer. Using segmentation to derive per-thread
state would allow i386 to make IRQ and task stack-sizes independent.
There are beginnings of this in the i386 PDA code.

A patch to allow 8K/8K is relatively simple and may serve your
purposes. vmalloc() of the task and IRQ stacks has negative
performance and resource scalability implications, though it's not
particularly involved. It also ensures no memory corruption can occur
from stack overflow save in the case of stack frames larger than a
page, where furthermore the procedure references distant locations
prior to close ones, such as a reverse array walk. Allowing larger
stacksizes than 8K doesn't seem to be of interest to you, probably due
to the negative resource scalability implications, though it may
stabilize some workloads.

I'm not sure what to say on the simplicity front apart from patches
consisting largely of Kconfig edits are demonstrably simple. There
really wasn't much to any of this from my POV, but I do understand
that others may differ particularly on the stack vmalloc() front.
The individual patches of the series are mostly independent save for
textual affairs, and I intended for users to cherrypick whatever
strategies they preferred as per the config options provided. An
individual patch for the preferred strategy can also be respun in
isolation, if any of those provided are considered desirable.

Otherwise I suppose I can actually make use of the PDA to make the
IRQ stacksize independent of the task stacksize.


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/