I would love to see this make it upstream. I use PaX/grsec under linux and one of my favorite things about them is that they try to enforce w^x.
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.
It changes a broad class of attack exploits to require return-oriented programming techniques to exploit. Are you seriously claiming that ROP isn't "that much harder" than injecting arbitrary code?
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.
Actually, though I deeply enjoy grsec and pax, I find it to work just fine with Arch. I have definitely considered gentoo hardened though; the notion of being able to rebuild everything exactly how I'd like it is pretty damn tempting. Thank you for the recommendation; everytime someone gives me a serious recommendation for Gentoo, I always have to take a moment and give it a more serious thought :)
I was going to post something about how I wonder how useful this is since my understanding is that JIT engines need to be able to write executable code to memory, and if you can't protect that, which seems to be the largest attack vector for browsers currently.
Then I actually looked at the post, and it's about enabling W^X on JIT pages in memory. Very cool.
I think I remember reading old articles about how they're doing this. Once the code has been JIT'd they put it on a page (or pages) by itself, and then toggle the write bit so it can be executed. Once it's JIT'd anyway it won't ever be changed, other than to maybe be dropped in favor of some other code. This still can have some security issues if someone can manage to get the JIT engine to output arbitrary code directly but it prevents a huge class of attacks of overwriting the JIT pages and getting the browser to then execute them. Or the usual stack overflows and other things of course.
> Once it's JIT'd anyway it won't ever be changed,
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.
Doesn't mapping the same physical memory into two places actually end up defeating the W^X bit entirely? Since you can write to the RW mapped page and have it change the RX page?
Those pages would be mapped at a different, random address while the executing code has an instruction pointer pointing right at the RX page.
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.
An individual function would often be smaller than 4K, and it's up to the JIT to decide how much to compile at one time, and you can also coalesce new code with old code to compact it.
That one uses WebKit. I wonder if anybody actually got Gecko to run on iOS. As I understand, there are "only" two problems - Apple not allowing other HTML/JS implementations, and Apple not allowing writable, executable memory. I don't know what the status of the first is, but you can get around the latter by just using an interpreter instead of a JIT (which is of course terribly slow).
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?
Prototype builds of Gecko running on iOS do exist, but they are not officially developed or maintained by Mozilla. You can track the progress of merging iOS support into the main Firefox repository in this bug:
Well, you certainly know more about Mozilla's iOS plans than I do :) but I thought Ted was just working on the patches on his own time, not in any official capacity.
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.