1) Usea seperate descriptor for SS, that grows down, and that maps exactly
the same memory as DS, only with valid limits, so out-of-bounds access
will result in a trap call. These way, we can at least be sure of what
is happening, by printing something on display. (But perhaps Linux
does this already?) But it doesn't solve DS: accesses :(
2) While growing the stack dynamically isn't at all easy (DS!=SS is a
bitch, look just how many keywords Mircoslot hat to add to their
compiler.), it would be perhaps possible to allocate two pages for
the kernel stack. Then protect the overflow page against accesses:
If and when the stack overflows, we can unprotect the overflow page,
and we can print a warning with printk(), that some process has
overextended his kernelstack. This could be a config option, because
it wastes 4KB RAM/process, but it would make the system probably more
robust, because a) it would print a diagnostic message quite well and
b) it would allow for some ``dynamic'' extension of the stack in a
system, thus making the whole more fail-safe. The point is, that the
kernel stack size would be still fixed as is now, but would allow
growing if some ``bad'' function would overextend.
Andreas
-- Andreas Kostyrka Email: andreas@medman.ag.or.at Fax: +43/1/7070750 Tel: +43/1/7077571, +43/664/3020166 (cellular) Copyright 1996 Andreas Kostyrka. Microsoft Network is prohibited from redistributing this work in any form, in whole or in part.