Announcement

Collapse
No announcement yet.

Write XOR Execute JIT Support Lands For Mozilla Firefox

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Write XOR Execute JIT Support Lands For Mozilla Firefox

    Phoronix: Write XOR Execute JIT Support Lands For Mozilla Firefox

    As another recent Firefox Nightly change besides enabling WebGL 2 by default is that Firefox's just-in-time compiler supports W^X protection...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    W^X does not add much security. These days ROP's have become commonplace.. W^X nigh on a moot point.

    Comment


    • #3
      Originally posted by Linux_Chemist
      Firefox really doesn't need any extra overhead, even 3%, the average user is running chrome/chromium purely for the speed.
      Wrong. Mozilla's JIT is very competitive these days. It's the layout engine that's responsible for the (perceived?) slowness.

      Also, the title is a bit optimistic, considering the feature won't be in the hands of most users for 3 more months or so.

      Comment


      • #4
        OpenBSD now ruining things outside their clusterf&^k of a project because there's nothing left in there to ruin.

        We should ban BSD.

        Comment


        • #5
          Originally posted by milkylainen View Post
          W^X does not add much security. These days ROP's have become commonplace.. W^X nigh on a moot point.
          The reason ROP is common place is because so many areas of writable memory have been marked non-executable. Shell code used to be able to use a buffer overflow to write it into stack and then execute it. That stopped working so now attacks are forced to use ROP. It isn't because ROP is easier.

          If the JIT memory is next to some kind of Javascript writeable array that is vulnerable to an overflow it would be trivial to write code into the executable memory. With this change that will no longer work.

          Comment


          • #6
            Originally posted by bug77 View Post

            Wrong. Mozilla's JIT is very competitive these days. It's the layout engine that's responsible for the (perceived?) slowness.
            Semi-wrong. Mozilla's Spidermonkey is actually faster than V8 in many cases, but the slowness of Firefox comes not from the layout engine, but from the fact that all tabs (and interface) uses one instance of spidermonkey. As fast as it is, it can't show off if more than one tab is opened.

            e10s only half-solves the problem by separating out "Firefox" from "content", so now content in tabs can't slow down Firefox... but they can still slow down (and crash) each other.

            Comment


            • #7
              Originally posted by Daktyl198 View Post

              Semi-wrong. Mozilla's Spidermonkey is actually faster than V8 in many cases, but the slowness of Firefox comes not from the layout engine, but from the fact that all tabs (and interface) uses one instance of spidermonkey. As fast as it is, it can't show off if more than one tab is opened.

              e10s only half-solves the problem by separating out "Firefox" from "content", so now content in tabs can't slow down Firefox... but they can still slow down (and crash) each other.
              You, sir, are right. I don't know what I was thinking when I wrote that.
              Although it can be argued that throwing all the JS in a single Spidermonkey instance yields better results (code-wise), there's no doubt sharing said instance between enough tabs will slow things down. It's probably why I'm completely ok with Firefox/Seamonkey: I don't keep many tabs open and I use NoScript.

              Comment


              • #8
                Originally posted by milkylainen View Post
                W^X does not add much security. These days ROP's have become commonplace.. W^X nigh on a moot point.
                What!?
                ROP exploit have become commonplace because of W^X and similar techniques. ROP exploits are far harder to write. And if the writable memory is executable you can potentially workaround almost every other mitigation technique: RelRO, randomic mmap, randomic malloc, PIE, Stack Smashing Protector, Stack Ghost, etc.

                Originally posted by Linux_Chemist
                Firefox really doesn't need any extra overhead, even 3%, the average user is running chrome/chromium purely for the speed.
                3% in the javascript engine. Web performance is constrained by the speed of DOM API, GPU acceleration and optimization of rendering pipelines. Faster js engine is helpful, but rarely critical.
                Last edited by rmiller; 04 January 2016, 10:54 PM.

                Comment


                • #9
                  Originally posted by Zan Lynx View Post

                  The reason ROP is common place is because so many areas of writable memory have been marked non-executable. Shell code used to be able to use a buffer overflow to write it into stack and then execute it. That stopped working so now attacks are forced to use ROP. It isn't because ROP is easier.

                  If the JIT memory is next to some kind of Javascript writeable array that is vulnerable to an overflow it would be trivial to write code into the executable memory. With this change that will no longer work.
                  Yeah. I know. I was just saying, W^X will not stop ROP's. Nowdays writing ROP's is pretty commonplace. Heck there are even tools for accumulating gadgets and gathering and construction of functions with gadgets... ROP's is a "off the shelf" method. But of course this adds to the "security". But to think that this will actually stop something.. that would just be plain wrong. But I think a parser and JIT like this is a slightly different story than general code with W^X. This might just benefit a great deal more from W^X.

                  Comment


                  • #10
                    Originally posted by Daktyl198 View Post

                    Semi-wrong. Mozilla's Spidermonkey is actually faster than V8 in many cases, but the slowness of Firefox comes not from the layout engine, but from the fact that all tabs (and interface) uses one instance of spidermonkey. As fast as it is, it can't show off if more than one tab is opened.
                    Ooh, thanks for that explanation. I had not understood that distinction, and I was puzzled why Firefox did so well in benchmarks but did not seem quicker than Chrome in heavy multi-tab usage. That explains it.

                    I believe Firefox is still quick enough that it's not a burden to use it.

                    So is there a "part two" of the Firefox Electrolysis project to address this? Or is the long term solution to this problem part of the Servo project?

                    Comment

                    Working...
                    X