559707 - TM: code chunk allocator is fallible, but Nanojit assumes it's infallible

Status: RESOLVED DUPLICATE of bug 624590

(Core :: JavaScript Engine, defect)

Description

[Nicholas Nethercote [inactive]]

Nanojit is designed to use an infallible allocator for code chunks.
From nanojit/CodeAlloc.h:

       // CodeAlloc's SPI.  Implementations must be defined by nanojit embedder.
       // allocation failures should cause an exception or longjmp; nanojit
       // intentionally does not check for null.
       //

       /** allocate nbytes of memory to hold code.  Never return null! */
       void* allocCodeChunk(size_t nbytes);

This is nice because it makes the code simpler in various places.  The
problem is that the implementations of allocCodeChunk() used by TM is not infallible.  It's in nanojit/avmplus.cpp, it uses mmap() on
Unix and other fallible things (eg. posix_memalign()) on other platforms.

In comparison, TR's implementation is infallible -- it either aborts or longjmps if it can't allocate the memory.

The only check for infallibility is an assertion in nanojit/CodeAlloc.cpp:

       void *mem = allocCodeChunk(bytesPerAlloc); // allocations never fail
       totalAllocated += bytesPerAlloc;
       NanoAssert(mem != NULL); // see allocCodeChunk contract in CodeAlloc.h

Other than that, Nanojit assumes the allocation succeeded.  In an
optimised build, where assertions are disabled, Nanojit will happily
start scribbling over the zeroth page in memory causing a crash.  (I'm marking this bug as security-sensitive for this reason.)

This seems bad, and is certainly counter to TM's general attempts to
detect and recover from out-of-memory situations.  Suggestions on how to address this are welcome.

Comment 1

[Jesse Ruderman]

> Nanojit will happily start scribbling over the zeroth page
>  in memory causing a crash.  (I'm marking
> this bug as security-sensitive for this reason.)

Attempting to write to the zeroth page in memory is a guaranteed safe crash in userland code on any sane OS.  Does this bug really need to be security-sensitive?

Comment 2

[Nicholas Nethercote [inactive]]

(In reply to comment #1)
> 
> Attempting to write to the zeroth page in memory is a guaranteed safe crash in
> userland code on any sane OS.  Does this bug really need to be
> security-sensitive?

If that's true, then no.  I was just being cautious.  Can you unmark it?  Looks like I'm unable to do so.

Comment 4

[Benjamin Smedberg]

I really don't think this needs to block, given that it always leads to an immediate safe crash, right?

Comment 5

[Nicholas Nethercote [inactive]]

Marking this as a duplicate of bug 624590, which subsumes it.