On Mon, 27 Jan 1997, Perry E. Metzger wrote:

> 
> Jason Thorpe writes:
> > On Mon, 27 Jan 1997 16:49:21 -0500 
> >  "Perry E. Metzger" <perry@piermont.com> wrote:
> > 
> >  > The 4.4 book claimed that most 4.4. ports already had a guard page at
> >  > the end of the kernel stack -- I was unaware that this was not the
> >  > case any longer.
> > 
> > So, the hp300 port had this long ago... it was a bit easier to do
> > in 4.4BSD because of the double-mapping of the kernel stack.  I.e.
> > the "guard page" address never changed, because the kernel stack
> > for all processes was mapped to the same address (kstack) upon
> > context switch.
> > 
> > When kstack went away, the stack checking stuff was garbage-collected.
> 
> This sounds, though, like its something that might be worth bringing
> back if it can be done. For all we know, lots of weird bugs would
> suddenly be found.

Perhaps I'm missing something, but would this idea (I'm about to suggest)
work? I'll freely admit I don't greatly understand this part of the
kernel, yet ;-)

I'm assuming that we know where, for each process, the kernel stack is
supposed to end, and that it's not suposed to change during the life of a
process (but might be different for different processies; I don't know).

What if we taked a real guard page to the end of the stack. It would be 4k
or 8k (whatever is the minimum), and we would fill it with some knowm
value. Or if there's data stored below the stack, it's just a buffer zone.
We fill it with a data value which we don't expect to be bassed to a
subroutine, like a word-unaligned address for an unmapped area. When ever
we context switch (or at other times like some stage of autoconfig), we
check to see that the values we stored are still there. If no, something
went wrong, and we note it.

This idea is different from a guard page in that we don't get a
screetching halt when we overflow, but would work on processors that would
freak if they didn't have a stack (ones that lack fall-back stacks).
Hopefully the overflow is small, so that the buffer protects whatever's
below it. And hopefully we don't overflow with code which gives the exact
flag value as a subroutine parameter.

Its not a perfect idea, but it might work, and certainly could give us
warnings we don't presently have, and should be platform independant.

Take care,

Bill