[PATCH] Expose custom MC-JIT memory allocation through the C API

[Sean Silva]

On Thu, May 16, 2013 at 3:10 PM, Filip Pizlo <fpizlo at apple.com> wrote:

> AFAIK, this is no less robust than an opaque struct. Both handle added
> functions gracefully, and neither can handle removed functions gracefully
> unless we do something crazy. The un-opaque struct just makes writing the
> code a bit easier, both for LLVM and for the client. But that's just my
> opinion. :-)
>

Unfortunately, it can break in the presence of shared libraries:

shared library A, compiled against LLVM API v1:
void runMCJIT(void) {
  LLVMMCJITMemoryManagerFunctions MCJMM; // v1
  setupMCJMM(&MCJMM);
}

shared library B, recently upgraded, compiled against LLVM API v2:
void setupMCJMM(LLVMMCJITMemoryManagerFunctions *p) {
  p->FunctionAddedInV2 = ...; // BOOM, overwriting caller's stack
}

Avoiding this kind of issue would force the API clients to replicate the
brittle sizeof checking in their own code.

Slightly related: Have you considered the security implications of using
LLVM in the browser? For example, AFAIK most LLVM code is not written to
properly handle OOM conditions and may be a vector for security issues. See
<http://comments.gmane.org/gmane.comp.compilers.clang.devel/19981>, which
is about clang, but I think also extends to LLVM itself. tl;dr,  Doug
Gregor says: "a safety-critical application should not be using Clang
in-process". Since LLVM is being used to compile code that interacts with
the page, sandboxing LLVM will not necessarily be enough protection since
an exploit could potentially hijack the compilation and return malicious
code.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130516/91f0408f/attachment.html>