[MLton] Patch: @MLton dumpable-core

[Matthew Fluet]

Applied, with some modifications:
* drop extra "Out of memory." messages
* use 'may-page-heap {false|true}' rather than 'dumpable-core' as
   the runtime option name.

Such an option was discussed in May 2006, though it was not implemented at 
the time:
   http://mlton.org/pipermail/mlton/2006-May/028783.html
   http://mlton.org/pipermail/mlton/2006-May/028796.html

We'll need to highlight this change in the next release, since this 
behavior has been used in practice (though, in some cases, without the 
knowledge of the user).

On Sat, 8 Dec 2007, Wesley W. Terpstra wrote:
> Without this patch MLton writes its entire heap to a temporary file when it 
> is unable to allocate memory. This was necessary to handle address space 
> fragmentation in programs using heap sizes 0.5-1.5GB. There are a number of 
> problems with doing this by default:
> 1. The temporary directory (or hard drive in general!) might not exist
> 2. An attacker might be able to retrieve sensitive information from the heap 
> (setuid programs do this too)
> 3. The core dump might unexpectedly fill up a user's quota, causing other 
> programs to fail
> 4. Even worse, it might fill up the temporary directory's filesystem, causing 
> other users' programs to fail
> 5. The windows port cannot delete open files, which means these temporary can 
> files sometimes get left behind
> 6. Most importantly, no one expects their program to suddenly dump 1GB to 
> disk
>
> People who previously needed this option are now be better served by using 
> the 64bit port. As there is far more address space, the fragmentation issue 
> is avoided. However, it could be the case that some 32-bit users still find 
> this useful, so the patch does not remove this feature outright.
>
> The patch adds an option used as follows
> ./my-program @MLton dumpable-core -- <my-args>
> which re-enables this behaviour. Programs will not by default create core 
> dumps.
>
> Setuid programs should be compiled with -runtime 'no-load-world stop'. This 
> prevents an attacker from starting the program in an incorrect state and also 
> prevents the use of 'dumpable-core' to trick an application into exposing 
> sensitive information.
>
> The patch also adds some hints in case the program runs out of memory.