[Mono-dev] JIT on iOS
kornelpal at gmail.com
Wed Dec 19 17:01:39 UTC 2012
I was thinking about the feasibility of having an interpreter on iOS but
making JIT functional would have a higher impact without significantly
increasing future maintenance requirements.
First I found https://gist.github.com/855607 that has two relatively
recent comments at the bottom that basically state that iOS 6 enables
changing writable non-executable memory to read-only executable.
I also found
summarizes that read-only executable pages are of little use for a JIT
producing multi-threaded code.
I haven't verified any of the claims because I don't usually develop on
iOS and mprotect with PROT_EXEC may not be accepted to the App Store for
I however think that with some clever hacks the current JIT could be
used with this W^X policy of iOS:
1. Using per-thread code pools could be used that avoids collisions for
code used only on a single tread.
2. Temporarily make non-executable but writable the last page of code
pool when adding a new method to avoid consuming too much memory pages.
Time spent in non-executable state can be lessened by generating code in
a separate buffer and only copying it to the code pool after is finished.
3. Resolve race conditions in the SIGSEGV handler by retrying code
execution. To avoid infinite loops IP address must be checked to point
to a code pool and code lock should probably be taken to ensure that the
page is marked as executable again before retrying. This way code is
ultimately able to be executed even when it takes multiple tries.
As long as the signal handler is not calling mprotect, only verifies
under the code pool that the page is executable, security is not affected.
Under low JIT load race conditions occur rarely, while under high JIT
load new code pages are allocated frequently, so race conditions quickly
stop occurring for any specific function.
As a conclusion I think that this could work fine with very little
modifications to JIT if PROT_EXEC is indeed supported.
I wonder if you have considered this solution or if you have any
information regarding the feasibility of using mprotect with PROT_EXEC.
More information about the Mono-devel-list