[mikeash]

There's nothing that prevents W^X and JIT from coexisting. All the JIT has to do is change the permissions on the generated code after generating it so that it becomes executable instead of writable. W^X just says that any given chunk of memory cannot be both writeable and executable at the same time.

What Apple does on iOS goes beyond W^X. They give you a one-way trap door, where you're not allowed to mark any memory as executable, ever, once it's marked non-executable. (Obviously, there is an exception made for the OS facilities that actually load your code from the disk, and an exception made for Safari's JIT, but us mere mortals don't get access to that stuff.)

As for the reason, it's hard to say. It's probably because of code signing and Apple's desire for control to prevent you from downloading and running unreviewed, unapproved code, although even that doesn't entirely make sense, because you can always embed an interpreter and download and run code in that.

[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.