[MLton] Re: Hppa

[Matthew Fluet]

> What matters is that MLton mmap()s memory always as PROT_READ|PROT_WRITE.
> The stack must also have PROT_EXEC in order for the trampoline to work to
> return from the signal handler. Since this was missing: segfault!
>
> Therefore, my patch changes the mmap() call to be PROT_EXEC also.

That is much too permissive.  As Henry pointed out, we (once, at the
beginning of the program) allocate an alternate signal stack.  Only this
one call to mmap needs PROT_EXEC.  No other allocated memory needs
execution privileges.

> I want to know if there is a security implication to this...
> Is MLton vulnerable to buffer overflow attacks?

MLton will use the underlying OS to do most of the primitive IO, so there
is always the possibility of attacking at that level.

> I thought array accesses were not always bounds checked, so it sounds like
> this probably is a concern. However, what else can I do?

All array accesses made by Array.{sub,update,...} and related functions
are bounds checked.  There various ways of subverting the system -- a (now
undocumented) compile time flag to turn off bounds checks, using MLton.FFI
functions to peek and poke at memory, etc.