Mozilla Research

Expanding the Foundations of the Open Web
Categories: Rust Servo

Another Big Milestone for Servo—Acid2

29 responses

Servo, the next-generation browser engine being developed by Mozilla Research, has reached an important milestone by passing the Acid2 test. While Servo is not yet fully web compatible, passing Acid2 demonstrates how far it has already come.

Servo’s Acid2 Test Result

Acid2 tests common HTML and CSS features such as tables, fixed and absolute positioning, generated content, paint order, data URIs, and backgrounds. Just as an acid test is used to judge whether some metal is gold, the web compatibility acid tests were created to expose flaws in browser rendering caused by non-conformance to web standards. Servo passed the Acid1 test in August of 2013 and has rapidly progressed to pass Acid2 as of March 2014.

Servo’s goals are to create a new browser engine for modern computer architectures and security threat models. It is written in a new programming language, Rust, also developed by Mozilla Research, which is designed to be safe and fast. Rust programs should be free from buffer overflows, reusing already freed memory, and similar problems common in C and C++ code. On top of this added safety, Servo is designed to exploit the parallelism of modern computers making use of all available processor cores, GPUs, and vector units.

The early results are encouraging. Many kinds of browser security bugs, such as vulnerabilities similar to Heartbleed, are prevented automatically by the Rust compiler. Performance comparisons on many portions of the Web Platform that we have implemented in single threaded mode are substantially faster than traditional browsers, and multi-threaded performance is even faster yet.

Servo has a growing community of developers and is a great project for anyone looking to play with browsers and programming languages. Please visit us at the Servo project page to learn more.

References

edited for clarity around Heartbleed

29 comments on “Another Big Milestone for Servo—Acid2”

Post a comment

  1. Alex Vranas wrote on

    Even Mozilla doesn’t understand Heartbleed…

    “Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler.”

    That’s pretty amazing seeing that Heartbleed is a SERVER vulnerability and has absolutely nothing to do with what kind of browser you are using!

    Unless Mozilla has bestowed upon Servo the magical power of updating software on third-party servers, then I am going to go ahead and assume that the person who wrote this blog post was hired for their writing ability, not their tech-savvy…

    Heartbleed doesn’t care if you are using the newest version of Servo, or Netscape Navigator 1.0. It’ll leak your PHPSESSID regardless.

    Reply

    1. Jack Moffitt wrote on

      I think you’ve misread the intent here. Rust prevents the kind of programming errors that led to Heartbleed. It obviously can’t prevent any vulnerabilities in software not written in Rust. I’ve updated the wording to try and make this clearer.

      Reply

      1. Francis wrote on

        I’m still not sure I understand the intent of that statement. Heartbleed was caused in part because OpenSSL implemented their own memory allocator wrappers, rather than simply using the standard library. Surely you’re not claiming that Rust makes it impossible to write your own (buggy) buffers over top of the standard library?

        Rust makes it more *difficult* than C to cause buffer overreads, but that’s probably also true of every other programming language in the world, except assembly language. Rust can’t make it *impossible* to cause that kind of bug if you try hard enough, nor can any Turing-complete language.

        What’s the intent of bringing Heartbleed into this at all? Just say “We have proper bounds checking, like every other programming language designed since 1970.”

        Reply

        1. Andy wrote on

          I think you’re reading into it too much. They’re not saying it’s absolutely impossible — obviously Rust has “unsafe” mode programmer can opt-in to and shoot themselves in the foot as hard as they like.

          The difference is that by default the Rust language forbids some of the most dangerous uses of pointers, the compiler can check whether usage is within limits defined as safe, and the runtime has array bounds checking.

          As a programmer you have several layers of safety you have to out”smart” before you make a Heartbleed-like bug.

          Reply

          1. Phillip Walters wrote on

            In addition to what you’ve said, the fact that you have to explicitly state when a block of code is unsafe means that you know which blocks of code require the closest scrutiny.

        2. Tinco wrote on

          Perhaps Rust does allow you to define your own memory allocator, but doesn’t allow you to make a buggy one? (not allow is perhaps a bit strong; maybe ‘strongly disencourages’ is better)

          Reply

      2. Bryan wrote on

        Congrats on the milestone. This says a lot about Rust as well as Servo. A long way to go from here to product, but the progress is exciting.

        How is memory footprint at this stage, and are the techniques in MemShrink being baked in from the start?

        Regarding Alex’s comment, perhaps this would be a better way to word it:

        “Many kinds of browser security bugs, including the types that lead to vulnerabilities such as Heartbleed, are prevented automatically by the Rust compiler.”

        Reply

        1. Jack Moffitt wrote on

          How is memory footprint at this stage, and are the techniques in MemShrink being baked in from the start?

          We haven’t specifically focused on analyzing memory yet, but it’s often in our mind. The good news is that our pursuit of speed means that it is a high priority. The smaller the representations of things, the better caching we get. We are working on researching improved representations of the DOM tree in memory for example, but don’t have anything concrete to talk about yet.

          Reply

        2. Simon Forman wrote on

          It was a poor choice of wording. Heartbleed certainly is not a “browser security bug”. Rust helps prevent the kinds of coding errors that heartbleed is an example of, and that is commendable, but the kind of people who would be pleased to learn that Servo has passed Acid2 (Awesome! Kudos Mozilla!) tend to be the kind of people who would be bothered by the unfortunate choice of language in that one sentence, as we’ve seen in this comment thread.

          Reply

    2. Bryce Fisher-Fleig wrote on

      HeartBleed DOES affect browsers. According to Symantec, “Heartbleed equally affects client software such as Web clients, email clients, chat clients, FTP clients, mobile applications, VPN clients and software updaters, to name a few. In short, any client that communicates over SSL/TLS using the vulnerable version of OpenSSL is open to attacks.” http://www.symantec.com/connect/blogs/heartbleed-poses-risk-clients-and-internet-things

      Reply

      1. Benoit wrote on

        Reread that statement. Rust is not a browser, it’s a programming language. What they mean is that rust protects against buffer overflow bugs.

        Reply

    3. This Guy wrote on

      Heartbleed can be exploited on t he Client as well. Maybe check your facts before being a dick.

      Reply

    4. no wrote on

      Heartbleed is just as much a CLIENT vulnerability as a SERVER vulnerability. Even you don’t understand Heartbleed.

      Reply

    5. Chris wrote on

      Actually, clients ARE vulnerable; see this information about “reverse heartbleed”: http://www.pcworld.com/article/2142808/reverse-heartbleed-puts-your-pc-and-the-internet-of-things-at-risk.html

      Reply

    6. Max wrote on

      >>“Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented >>automatically by the Rust compiler.”
      >
      >”That’s pretty amazing seeing that Heartbleed is a SERVER vulnerability and has absolutely nothing to do with what kind of browser you are using!”

      That wasn’t the point. The point was that using Rust on the server would have prevented the Heartbleed bug.

      Reply

    7. gabriel wrote on

      just read “reverse heartbleed” where you read heartbleed.. sigh.

      PS: but mozilla blog does not understand email. i can’t enter + in my email…

      Reply

    8. Eric S wrote on

      Rust and Servo are not the same. If a web server were written in Rust for instance, heart bleed wouldn’t be an issue. It is of course possible to make a heart bleed type error in Rust with unsafe code, but the idea is these types of programmer errors don’t happen in practice following proper Rust coding style.

      Reply

    9. evolighting wrote on

      I think Mozilla means,while using rust the case heart bless won’t happen.there are nothing about broswer

      Reply

  2. Bryce Fisher-Fleig wrote on

    False — heartbleed equally affects browsers, email clients, or any TLS communications according to symantec:

    “Heartbleed equally affects client software such as Web clients, email clients, chat clients, FTP clients, mobile applications, VPN clients and software updaters, to name a few.”

    Reply

  3. Andy wrote on

    Congratulations. It’s encouraging to see that it’s still possible to write a new engine from scratch, and a safe and finely parallellized one might be exactly what we’ll need in the future!

    Reply

  4. John J wrote on

    So when are you re-writing OpenSSL in Rust!?

    Reply

  5. Hervé Renault ( wrote on

    Performance comparisons on many portions of the Web Platform that we have implemented in single threaded mode are substantially faster than traditional browsers, and multi-threaded performance is even faster yet.

    Exciting read ! But can you be more precise ? What is the test case ?
    I’m eager to know more about this.

    Reply

    1. Jack Moffitt wrote on

      Exciting read ! But can you be more precise ? What is the test case ?
      I’m eager to know more about this.

      Please join and/or browse the archives of the dev-servo mailing list. The numbers and methodology are discussed there.

      Reply

  6. Skoua wrote on

    Is Servo eventually going to replace Gecko?

    Reply

  7. JIghtuse wrote on

    Link for the history: https://imgur.com/a/O667X
    Good work, folks!

    Reply

  8. James Napolitano wrote on

    Excellent work with Servo! That’s some fast progress for a new layout engine. I’d like to ask a few general questions about the project:
    1) Will Servo support browser plugins? (I’d assume no, which will eliminate a lot of complexity.)
    2) Servo isn’t going to support or use XPCOM or XPConnect, but what about XUL? If not, then will Servo need a separate front end than Firefox?
    3) How much code from Gecko will be reused in Servo? The graphics code (azure) and javascript engine are, but what about, say, the new WebIDL DOM bindings? I’d assume the layout code would be all new.

    Reply

    1. Jack Moffitt wrote on

      We’re not worrying about plugins right not. Certainly we have no intention of backwards compatibility with existing plugins.

      We’re not planning to support XUL, and we’re not far enough along to know what we want to do with a frontend. We’re focusing on embedding so that people can innovate on how the engine is used.

      We reuse as much as we can when it makes sense. For example, the WebIDL dom bindings aren’t reused, but we started from the Paris bindings generator and made it output Rust code. Media codecs, WebRTC might be another are where we reuse heavily too. If we’re lucky and after Rust stabilizes some, we might be able to have code the other direction as well; safer libraries that Gecko can use.

      Reply

      1. James Napolitano wrote on

        Ah, those all sound like good plans. Just for clarity, by plugins I meant NPAPI ones. Is that what you were referring to? I thought Mozilla was hoping to phase out plugins in favor of the web platform (more so now that Chrome will drop support for NPAPI).

        Also, with FirefoxOS, the frontend is all in HTML (with some extensions), so once Servo is far enough along would you be able to simply swap it in for Gecko there?

        Reply

        1. Jack Moffitt wrote on

          We are not planning to add NPAPI support to Servo at all.

          We will definitely support some kind of add on system, but it’s not something we’ve thought a lot about at the moment.

          Reply

Leave a Reply

Your email address will not be published. Required fields are marked *