[mmastrac]

They can co-exist, but not in the same process. If there's a JIT running in the same process as my C-based program, it has the permissions as I do.

Any secure JIT would have to exist out-of-process with extended permissions, and would require some sort of RPC back-and-forth as the code was shuttled between the two processes.

[mikeash]

W^X is not some code word for "secure". It has a specific meaning, and that specific meaning is completely compatible with JIT code. All it means is that you have to call mprotect() after generating code.

One can debate the security implications of allowing programs to mark code as executable at all, but that debate is unrelated to W^X.

[0x0]

I'm guessing there are two reasons -

1. Preventing any app code from allocating memory and setting it executable: Apple doesn't seem to want to allow dynamically adding code to any app store apps. See: No .dylib support, the earlier bans on all types of interpreters, etc. It would be too easy to get a "Loader"-type app into the app store that could download and execute random app code from the internet that hasn't been vetted by the app store review team. (Emulators, plugins, addons that call private APIs, etc. etc. etc.)

2. Limiting the vulnerability surface: Reduce the risk of webkit exploits targeting app store apps (or even non-webkit random exploits in the app's code allowing loading of shellcode)

[mmastrac]

You are correct. I'm (incorrectly) using W^X here to refer to Apple's W^X, which is effectively setting W^X on pages at image load time for preventing execution of dynamic code -- and possibly for security, but I imagine that is more of a bonus from their point of view.