[MLton] Re: Hppa

[Matthew Fluet]

> > The MLton stuff uses sigaltstack() (a system call) which should set things
> > up so that an alternate stack is used on all signals.  This is meant exactly
> > for processes that are doing funny things with the stack register.
> > Looking via google (for sigaltstack() and HPPA) I see items about kernel
> > patches as recently as May of this year to fix it.
>
> The alternate stack which MLton sets up is also not PROT_EXEC.
> Therefore, whether an alternate stack is used or not is irrelevant.
> So, those patches to the kernel aren't going to fix things for us.
>
> Prior to sigaltstack(), ssmmap->smmap->GC_mmapAnon->mmapAnon->mmap is called.
> Does 'ssmmap' mean signal stack mmap?

I think we originally coined it as "super-safe" mmap.  It protects the
boundaries of the signal stack with inaccessible memory.  I seem to recall
Henry looking at some kernel code and discovering that there are only very
loose checks on how to use an alternate signal stack; something along the
lines that if the stack pointer was "close enough" to the registered
alternate stack, the kernel wouldn't bother adjusting to "exactly" the
alternate stack.  Since we can use the stack pointer as a general purpose
register (in the x86 native backend), it could end up with an arbitrary
integer value, which might be enough to fool the kernel into running the
signal handler too close to the edge of the alternate stack.  Thus, the
dead zones to protect against this very rare possibility.

> If so, in platform/ssmmap.c it might make sense to add another mprotect line
> which adds the PROT_EXEC for the middle. What do you think? I will try this.
> At least this way everything else is not executable.

That sounds right.  I don't see any other calls to ssmmap, so you might as
well label it as the "Signal Stack mmap".