<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On May 16, 2013, at 3:20 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr">On Thu, May 16, 2013 at 3:10 PM, Filip Pizlo<span class="Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:fpizlo@apple.com" target="_blank">fpizlo@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto">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. :-)</div></blockquote><div><br></div><div>Unfortunately, it can break in the presence of shared libraries:</div><div><br></div><div><div>shared library A, compiled against LLVM API v1:</div><div>void runMCJIT(void) {</div><div> LLVMMCJITMemoryManagerFunctions MCJMM; // v1</div><div> setupMCJMM(&MCJMM);</div><div>}</div><div><br></div><div>shared library B, recently upgraded, compiled against LLVM API v2:</div><div>void setupMCJMM(LLVMMCJITMemoryManagerFunctions *p) {</div><div> p->FunctionAddedInV2 = ...; // BOOM, overwriting caller's stack</div><div>}</div><div><br></div><div>Avoiding this kind of issue would force the API clients to replicate the brittle sizeof checking in their own code.</div></div></div></div></div></div></blockquote><div><br></div><div>Why would you do this? I.e., why would you ever want to have initialization of the MCJIT memory management functions span multiple shared libraries?</div><div><br></div><div>Loads of C APIs are based on C structs, and use the idiom that I used. BerkeleyDB does this. A bunch of libc APIs do this. Of course when writing C code, if you #include a header that has a struct, and you pass a pointer to that struct to a separately compiled shared library that may have seen a different version of the header, you have to take precautions. I'm not sure if this concern should drive the design here, particularly when it makes no sense to have two different shared libraries cooperatively setting up a struct of callbacks for the MCJIT.</div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><div>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 <<a href="http://comments.gmane.org/gmane.comp.compilers.clang.devel/19981">http://comments.gmane.org/gmane.comp.compilers.clang.devel/19981</a>>, which is about clang, but I think also extends to LLVM itself. tl;dr, Doug Gregor says: "<span style="line-height: 19px; text-align: justify;">a safety-critical application should not be using Clang in-process". </span></div></div></div></div></div></div></blockquote><div><br></div><div>"Safety-critical" is a term of art that refers to things where failure could cause a person to die. Nobody will die if the browser's WebContent process crashes due to an unhandled OOM resulting from a JavaScript program that had a large hot function, which LLVM couldn't compile in the available memory.</div><div><br></div><div>Of course we care about stability, security, and compliance; but WebKit already pretends that memory allocations succeed, and will crash if they don't. That's not a security vulnerability. It's a pragmatic choice: WebKit has to already do so many crazy things that making it safety-critical would be a gargantuan task, and is probably beyond the scope of what any browser vendor could do today.</div><br><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><span style="line-height: 19px; text-align: justify;">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.</span></div></div></div></div></div></div></blockquote><div><br></div><div>True. This is a good point. My own view on this is that LLVM is already hardened enough - in terms of codegen soundness - that it won't be the longest pole in the tent.</div><div><br></div><div>-Filip</div><div><br></div></div></body></html>