Improving browser security

I wonder if he&#x27;s aware of this NDSS 2015 paper: <a href="http://www.internetsociety.org/doc/exploiting-and-protecting-dynamic-code-generation" rel="nofollow">http:&#x2F;&#x2F;www.internetsociety.org&#x2F;doc&#x2F;exploiting-and-protecting...</a><p>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.<p>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&#x27;s plausible to get rid of the use of write+execute memory segments without sacrificing a lot of performance?

Nearly every browser engine has or had patches at one time to accomplish this. Its a call to mprotect&#x2F;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.

Not just browsers. Some other common packages that also use JIT include:<p>Java Python (PyPy) Qemu Valgrind PCSX Yabause Mupen64plus

Fixing open source JITs to support Windows x64 SEH properly is on my wishlist for MS Open Tech.

&gt; 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<p>It really annoys me to see something like this. &quot;Oh, well we didn&#x27;t upgrade our OS to that much more secure feature because it would&#x27;ve meant breaking compatibility with a few popular apps...<i>2 decades ago</i>&quot;.<p>My point is whether it breaks compatibility or not is irrelevant. The solution is simple: set a <i>reasonable</i> but very clear deadline for when you&#x27;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&#x27;re requiring of those developers.<p>But not doing it <i>at all</i> because it would break compatibility with some apps is just inexcusable to me. I&#x27;m also quite disappointed Microsoft hasn&#x27;t implemented all the EMET features into Windows 10 and may not even consider doing it until Windows 12.