TL;DR version: the JIT becomes a separate process that maps the code cache as RW, while the browser itself only sees a RX mapping. They also discuss why flipping between RW and RX in the same process is insecure (basically, TOCTTOU attacks from different threads).
So, this note says that browser JITs are the main thing that typically needs writable and executable memory right now, and the author (Ted Unangst) is going to try to fix that.
It seems natural to think that JITs would want that feature (so they can compile things into native code and then jump into it). Can someone who has worked with DOM rendering or Javscript interpreters opine on whether it's plausible to get rid of the use of write+execute memory segments without sacrificing a lot of performance?
On Firefox and WebKit (but not Chrome) you can already do that, by disabling the JIT and thereby only running in the interpreter.
You do lose a large amount of speed on sites that have JS doing heavy things. However, on a lot of the web, you don't need heavy JS, so you might not notice it on a news site or your email site. Try to play a game, though, and it'll be obvious.
Nearly every browser engine has or had patches at one time to accomplish this. Its a call to mprotect/VirtualProtect after writing native code to memory. Theres a performance hit to JIT engines that update emitted code often due to dynamic JS typing. You could always just turn off the JIT engine and execute the slower bytecode. But thanks for coming down from the mountain to enlighten us, again.
Did you even read the email? It is explicitly stated that W^X modifiable with mprotect is something they are seeking to eliminate.
Due to timing issues its essentially impossible for the concept you laid out to ever provide reliable mitigation inside a program that is throwing mprotect around in a multi-threaded environment anyways.
> The policy has remained advisory because many JIT engines use such memory and
enforcing mandatory W^X would mean such programs no longer run on OpenBSD
It really annoys me to see something like this. "Oh, well we didn't upgrade our OS to that much more secure feature because it would've meant breaking compatibility with a few popular apps...2 decades ago".
My point is whether it breaks compatibility or not is irrelevant. The solution is simple: set a reasonable but very clear deadline for when you'll adopt that feature and those apps will stop working unless they adapt. You could make it 1 year, 2 years or even 5 years, depending on how big of a change you're requiring of those developers.
But not doing it at all because it would break compatibility with some apps is just inexcusable to me. I'm also quite disappointed Microsoft hasn't implemented all the EMET features into Windows 10 and may not even consider doing it until Windows 12.
[+] [-] ahomescu1|11 years ago|reply
TL;DR version: the JIT becomes a separate process that maps the code cache as RW, while the browser itself only sees a RX mapping. They also discuss why flipping between RW and RX in the same process is insecure (basically, TOCTTOU attacks from different threads).
[+] [-] schoen|11 years ago|reply
It seems natural to think that JITs would want that feature (so they can compile things into native code and then jump into it). Can someone who has worked with DOM rendering or Javscript interpreters opine on whether it's plausible to get rid of the use of write+execute memory segments without sacrificing a lot of performance?
[+] [-] azakai|11 years ago|reply
You do lose a large amount of speed on sites that have JS doing heavy things. However, on a lot of the web, you don't need heavy JS, so you might not notice it on a news site or your email site. Try to play a game, though, and it'll be obvious.
[+] [-] chrisrohlf|11 years ago|reply
[+] [-] chrisrohlf|11 years ago|reply
[+] [-] throwaway2048|11 years ago|reply
Due to timing issues its essentially impossible for the concept you laid out to ever provide reliable mitigation inside a program that is throwing mprotect around in a multi-threaded environment anyways.
[+] [-] meow56789|11 years ago|reply
Java Python (PyPy) Qemu Valgrind PCSX Yabause Mupen64plus
[+] [-] yuhong|11 years ago|reply
[+] [-] higherpurpose|11 years ago|reply
It really annoys me to see something like this. "Oh, well we didn't upgrade our OS to that much more secure feature because it would've meant breaking compatibility with a few popular apps...2 decades ago".
My point is whether it breaks compatibility or not is irrelevant. The solution is simple: set a reasonable but very clear deadline for when you'll adopt that feature and those apps will stop working unless they adapt. You could make it 1 year, 2 years or even 5 years, depending on how big of a change you're requiring of those developers.
But not doing it at all because it would break compatibility with some apps is just inexcusable to me. I'm also quite disappointed Microsoft hasn't implemented all the EMET features into Windows 10 and may not even consider doing it until Windows 12.
[+] [-] Canada|11 years ago|reply