[MLton] Re: Hppa

[Wesley W. Terpstra]

On Thu, Dec 16, 2004 at 08:48:23AM +0100, Wesley W. Terpstra wrote:
> There are some regression with signals and threads, but mlton can at
> least rebuild itself now.

I finally found the problem... talk about obscure!

The threading stuff was crashing because whenever the signal was delivered
to cycle the context it died. Basically, whenever a process received a signal
it would segfault.

What is obscure is why. You won't find the problem with a debugger. ;)
The code that causes the problem is somewhere between the kernel and libc.
It seems that on hppa the return from a signal handler is arranged via a
trampoline on the stack, which is executable code. For normal C programs
this present no trouble. However, MLton manages the stack itself.

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.

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

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

PS. MLton threads are pretty cool!
It's too bad preemption won't work under windows... (no signals)

-- 
Wesley W. Terpstra