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

Quite honestly, I don't believe this.  Even if 4.4BSD had unmapped
page(s) below the user area, the kernel stack could still overflow
into the user area.  (Indeed, that's the problem that the sparc port
is seeing right now...)

Some 4.4BSD ports (hp300 comes to mind, if i
recall) did have the capability to check SP at trap time to make sure
the kernel stack hadn't overflowed, but that doesn't even come close
to guaranteeing safety.


> I would feel much more comfortable if we had them -- this silent
> overflow thing may be leading to all sorts of inexplicable problems
> (and not just during autoconfig).

I don't disagree with this.  It's just not quite as simple to
implement as one might like.  8-)


> > It also means that, on most/many architectures, kernel stack overflows
> > can't be handled reasonably.  Since as of the time of the overflow,
> > there's no space left to push data on to the stack, on most
> > architectures there's no place to put the stack frame that indicates
> > that the stack grew into the guard page...  Some architectures will
> > deal with this sanely (e.g. on the alpha, i get sent back to the
> > firmware with a KSP INVALID fault 8-), but many e.g. m68k will appear
> > to spontaneously reboot.
> 
> At least, though, we might learn that we need to expand the stack by a
> page, or that we have a kernel bug wasting kernel stack. I prefer to
> know than not knowing.

Actually, what we'd end up seeing is spontaneous reboots.

figuring out what's causing an apparently- spontaneous reboot can
be ... difficult.  8-)


certainly, if you're concerned about system integrity you want the
system to reboot in this case, even if you don't know why it did.



chris