1. 28
  1.  

  2. 5

    Honestly the whole time I was reading through this I just kept thinking, “I’m surprised it’s taken this long.” The pattern of where security vulnerabilities come from that was presented in this document has been known at Mozilla for a long time, and they have been investing in fixing it for nine years. Chrome has always had pretty great security (its sandbox model in particular is great technology and Mozilla is still catching up to it IIRC) but you’d think they would’ve been thinking about this a long time ago.

    1. 3

      Getting rust into the browser started much later and the main push with stylo (servo’s style engine) in Firefox 57 was mostly for performance (achieved due to the secure and safe multi core parallelism, I admit).

      The sandbox bit is mostly true. We use almost the same sandboxing code but with different settings.

      1. 2

        Definitely, but my point is that Mozilla has been investing in this long-term. Rust was specifically designed to rewrite big parts of Gecko in, and one of the big reasons for that rewrite is to completely kill memory safety bugs (I know you already know all this; I’m mostly saying it for the benefit of those who might not).

        The Chrome folks don’t have to invent a new language because Mozilla has already developed an excellent one for them. But if they want to really go all the way, like Firefox is doing, they still have to rewrite huge components of Blink. Developing Servo took years and it is still not able to completely replace Gecko. If the Chrome team is only starting to look at this now, they’re going to be playing catch up for a very long time.

        1. 2

          I am not sure about long catch up. I found inventing Rust to be a long and serial process, but Rewriting It In Rust is a pretty parallel process which you can do quickly by throwing more people.

          1. 2

            And Google can easily afford those people. Tech companies not addressing memory safety is mostly just apathy at this point.

    2. 1

      A key limitation is that the process is the smallest unit of isolation, but processes are not cheap.

      While Rust is a partial solution, it’s a pretty heavyweight tool and there are place (eg JIT) that require writing a lot of unsafe Rust anyway. I’m hoping to see more system-level tools like nanoprocesses, which restrict at codegen time which areas of memory a given module can access.

      1. 2

        I’d like to challenge the JIT claim. https://github.com/nbp/holyjit is a JIT that has exactly 3 uses of unsafe in its codebase. It’s not used anymore, most of the knowledge went into cranelift, AFAIK, which has 66 lines of unsafe for a quite vast codebase.

        1. 1

          You’re right, I wrote very imprecisely. My intended point was that it’s loading machine code into memory and executing it, and that machine code is not safe rust so is not guaranteed to be memory safe and is going to need some different method of protection. But I should have just said unsafe code rather than unsafe rust, and I agree that the surrounding rust code can be mostly safe.

          1. 1

            Right, thanks for the clarification! You are correct, code generation bugs exist and I have met them once or twice.

            1. 1

              I guess another way of saying it is that if you have one line of unsafe rust that says “execute this bit of machine code” then the actual trusted base for memory safety is not just that unsafe line but all the code that is responsible for writing the machine code. Bugs in any part of that can lead to violating memory safety down the line. So the boundary for presenting a safe interface is going to be much bigger than just the lines that are actually marked unsafe.

      2. 1

        Infer catches stuff like this. I wonder if they’ve tried it.

        1. 2

          I tried creating an AUR package for infer, but I spent a week packaging its ocaml dependencies before discovering it failed with an error after compiling for 30 minutes.

          1. 1

            Chromium uses/used Semmle. Looks like it found some good bugs: https://bugs.chromium.org/p/chromium/issues/list?can=1&q=label%3AFound-With-Semmle

            Infer, like all static analysis, probably produces false positives (never used it personally). This makes them a costly/large undertaking to bring up on large code bases, normally it is worth the effort in my experience though.

          2. -1

            Taking a massive amount of code and throwing more languages on the fire seems like they are generating a massive amount of work for build farms

            1. 10

              Do you have a better suggestion? C++ hits a point of diminishing returns. Even after using incredible static analysis tools, Address santitization libraries, careful auditing, and hiring some of the best C++ devs there are. They are still only just barely staying ahead of the attackers. Something is going to have to give eventually.

              Build farms may take a lot of resources for the project but is that cost less than the cost of security issues for a majority of the internet’s users?

              1. 2

                Can we try less code? Or the same code in smaller units?

                1. 2

                  That’s certainly a laudable goal. However even reducing the code can only take you so far. At some point if you want to improve the memory safety of the codebase for something as necessarily complex as the browser you have to reach for better tools. Languages built to preserve memory safety are a great tool for this.

                2. 1

                  They could also use or build more tools than what’s available. I don’t think they’ve gone nearly far enough on that. Another option is reviving C++ to C compilers to use tools for C on C++ codebases. There’s tons of verification and testing tooling for C. Some prove absence of errors. I’d expect that to get even more wins using all that.