Unfortunately, a ton of programs break this policy (seemingly for no benefit). Having upstream firefox respect w^x anyway would mean I could remove its exception under PaX and a whole class of possible security flaws just GoAway™.
Ideally, I'd love to see Linux embrace w^x generally, but the kernel devs do not seem terribly interested in that. Either way, keep up the rockin' work OpenBSD team!
Edit: Oh wait! The patch for this is actually upstream! This bit of news is OpenBSD enabling it! That's awesome! /me tries to rebuild firefox with the patch enabled.
Technically not true, they don't go away, they're just harder(and not that much harder) to exploit.
Second of all: ugh! Dear HackerNews team, please fix your URL matching algorithm so it doesn't include <> in URLs; they're actually explicitly recommended by the URI RFC as delimiters.
The other paper shows that this technique is Turing complete.
But yes, basically W^X is defeated.
Yes I am.
Then I actually looked at the post, and it's about enabling W^X on JIT pages in memory. Very cool.
That's not necessarily how it works. JITs often use inline caches that get populated at runtime. JITs usually implement W^X by mapping the same physical memory into two different address ranges. Once as RW for modification and once as RX for execution.
Having a single mapping is possible, but comes with performance penalties because execution needs to reach a safe/bailout point where that can happen instead of just atomically patching the code.
It's much more difficult getting access to the JIT's internal data structures, traversing them to find the correct RW page, then modify it, then jump to the same place in the RX page. If you already have that much control you're probably not far from getting the JIT to emit arbitrary code anyway.
Note that writing to ICs can happen from a different thread, so the current thread stack does not need to know much of the JIT's internal data.
I would recommend, however, watch from the beginning.
Or, you decide Apple is never going to let your engine on the App store, and then you just include the JIT. The enforcement is done at time of submission to the app store, not at runtime. IIRC, you can just call a certain function to mark a memory region as writable or executable, but Apple detects this call statically.
I further wonder if you could just distribute binaries, outside of the app store, and your users would have $99 developer accounts, and run a little script to "build their project with XCode", signing and installing it to their device?