22 ms·

Experimenting with Rust in Chromium

221 points by navigaid 4y ago

ntoskrnl 4y ago
It was bound to happen eventually. Big projects like Chromium tend to move slowly so it will probably be a few years before any Rust code ends up in a shipped release. But this is a great start!
- jupp0r 4y ago
  I don’t think Chrome is moving slowly. They are on the very edge of web technology. They are for example relatively fast at adopting modern C++ standards (compared to other big code bases). [1] [1] https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++-features.md https://chromium.googlesource.com/chromium/src/+/HEAD/styleg...
- keyle 4y ago
  Chrome is indeed big, however calling them slow is incorrect. In fact there are articles of people burning out with the release process of Chrome, left behind by the sheer speed at which the project is moving forward.
  - legolas2412 4y ago
    Can you give examples for the articles? Very interested in knowing
  - summerlight 4y ago
    This is so true. There were tens of Chromium based browsers which had a good niche market interests but eventually failed to keep up with Chromium's super fast development pace. I'm pretty sure that the Edge team spends lots of their eng time solely on rebasing and one of the key factor for a successful Chromium based-browser project is to manage clean separation of your domain code and Chromium codebase. Otherwise, your team member will be quickly burnt out and leave the team.
  - ntoskrnl 4y ago
    You're right. I meant to say big projects tend to be conservative with adopting new technologies. I didn't mean to imply anything about development pace.
deleted 4y ago
[deleted]
riwsky 4y ago
Even though it'd be a while before this really affects the Chrome codebase, it's a real testament to how well Rust nails the safe-but-low-level niche. Google does not lack resources to tool (or staff!) a C++ codebase correctly, nor does it lack resources to build languages[1] targeting these specific problems; that they'd consider Rust isn't just because "it's there". [1] https://github.com/google/wuffs https://github.com/google/wuffs
- cletus 4y ago
  Story time. I worked at Google years ago and there was a presentation once done on some optimizations done on Chrome performance. This is probably 10 years ago now. So C++ has std::string of course. C libraries however use "const char ", which has lots of problems. The C++ designers allowed you to avoid friction here by allowing you to pass a std::string to a function expending a const char . Technically, this is an operator method. It was discovered that the Omnibar in Chrome went through many layers of translations between std::string and const char *, back and forth, such that there were approximately 25,000 string copies per keypress in the Omnibar. So my point is that even with a ton of resources writing good, efficient and performant C++ is still nontrivial. And that's really the point of Rust (well, one of them).
  - steveklabnik 4y ago
    HN comments on this story: https://news.ycombinator.com/item?id=8704318 https://news.ycombinator.com/item?id=8704318
  - fractalb 4y ago
    If all the dependent C libraries are replaced with C++ versions, then the no.of translations will become zero?
    - woodruffw 4y ago
      Nominally, yes. But conversions between C strings and `std::string` are just a small corner of the problem: C++ makes it very easy to accidentally call copying constructors and perform nontrivial copies when doing e.g. implicit argument conversion.
nikeee 4y ago
> The language, at least for now, is Rust. What are the alternatives in the context of Chromium development as a replacement for C++?
- pjmlp 4y ago
  https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... See "Using safer languages anywhere applicable".
  - lordofgibbons 4y ago
    Interesting that Java, Swift, and Javascript are listed there but not Go. I wonder why
    - pjmlp 4y ago
      Because they are relevant on the context of Android, Apple OS, and ChromeOS respectively, as the main OS languages alongside C and C++.
bluejekyll 4y ago
> Rust is not yet available on all Chromium platforms (just Linux and Android for now) The beginning of this sentence didn’t surprise me, but the fact that it’s just Linux and Android did. Rust supports macOS and Windows really well, so I wonder what the gap is here? > Facilities and tooling in Rust are not as rich as other languages yet. Is this meant in the context of Chromium?
- flohofwoe 4y ago
  AFAIK it took years for the Chrome code base to allow a different C++ compiler than MSVC for the Windows build (e.g. Clang is now supported too). It's not surprising that they don't provide Rust support for all platforms right from the start.
- cmrdporcupine 4y ago
  The amount of things that have to happen for a modification to the build environment for a target is more than just that the tooling exists and is supported on those platforms. Picking just one piece: Consider that Chromium builds happen in a distributed build farm. There's multiple variants of this (goma, rbe). I'd imagine those systems would have to be modified to support the Rust toolchain for that target. And it looks like this work is built around making GN/ninja support Rust, just using cargo directly. So that's what they likely mean by "not as rich as other languages yet."
staticassertion 4y ago
I hope this works out. A memory safe browser would be a huge win for security.
- brabel 4y ago
  Are there many exploits caused by memory issues in Chromium?
  - staticassertion 4y ago
    Yes, I believe literally every single 'in the wild' exploit has abused memory unsafety, as well as hundreds of vulnerabilities every year.
    - brabel 4y ago
      That's strange... if they'd written the code in a memory safe language, say, Java... there wouldn't be any vulnerability? I don't know... I see plenty of vulnerabilities in the Java world, no memory unsafety needed.
      - UncleMeat 4y ago
        Vulns exist in Java applications. Logic bugs can open all sorts of doors to exploitation. But empirically we observe that a huge portion of real vulnerabilities in applications written in C or C++ are memory errors. We've spent decades trying to get people to write C and C++ applications without these errors and utterly failed. A browser written in a memory safe language won't be free from vulns but it will be free from a huge class of recurring and very serious vulns.
      - staticassertion 4y ago
        The question was if the exploits were due to memory safety. The answer is, yes, 100% of them are due to memory safety. As for Java, quite a lot of the exploits against it (when it was a browser plugin) were in fact memory safety issues in the VM. But more recently what we see are serialization issues, which Rust also does not have.
blub 4y ago
I have a hard time imagining a more accidentally complex piece of software than a web browser written in C++ and in Rust. All the chaos of the so-called web standards, decades of accumulated C++ complexity and the eccentricity and burgeoning complexity of Rust on top. Getting assigned to such a project must be akin to punishment.
- saagarjha 4y ago
  In chaos some see order.
- dblohm7 4y ago
  Not really. That’s a typical workday for many Gecko developers. Some useful guidelines made it pretty straightforward: https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation
gitgud 4y ago
It's funny that it was created in Mozzila and first used in the [1] servo browser, and now is getting adopted by Mozzila's rival Chromium [1] https://en.m.wikipedia.org/wiki/Rust_(programming_language) https://en.m.wikipedia.org/wiki/Rust_(programming_language)

221 points by navigaid 4y ago

It was bound to happen eventually. Big projects like Chromium tend to move slowly so it will probably be a few years before any Rust code ends up in a shipped release. But this is a great start!

jupp0r 4y ago
I don’t think Chrome is moving slowly. They are on the very edge of web technology. They are for example relatively fast at adopting modern C++ standards (compared to other big code bases). [1] [1] https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++-features.md https://chromium.googlesource.com/chromium/src/+/HEAD/styleg...
keyle 4y ago
Chrome is indeed big, however calling them slow is incorrect. In fact there are articles of people burning out with the release process of Chrome, left behind by the sheer speed at which the project is moving forward.
- legolas2412 4y ago
  Can you give examples for the articles? Very interested in knowing
- summerlight 4y ago
  This is so true. There were tens of Chromium based browsers which had a good niche market interests but eventually failed to keep up with Chromium's super fast development pace. I'm pretty sure that the Edge team spends lots of their eng time solely on rebasing and one of the key factor for a successful Chromium based-browser project is to manage clean separation of your domain code and Chromium codebase. Otherwise, your team member will be quickly burnt out and leave the team.
- ntoskrnl 4y ago
  You're right. I meant to say big projects tend to be conservative with adopting new technologies. I didn't mean to imply anything about development pace.

deleted 4y ago

[deleted]

riwsky 4y ago

Even though it'd be a while before this really affects the Chrome codebase, it's a real testament to how well Rust nails the safe-but-low-level niche. Google does not lack resources to tool (or staff!) a C++ codebase correctly, nor does it lack resources to build languages[1] targeting these specific problems; that they'd consider Rust isn't just because "it's there". [1] https://github.com/google/wuffs https://github.com/google/wuffs

cletus 4y ago
Story time. I worked at Google years ago and there was a presentation once done on some optimizations done on Chrome performance. This is probably 10 years ago now. So C++ has std::string of course. C libraries however use "const char ", which has lots of problems. The C++ designers allowed you to avoid friction here by allowing you to pass a std::string to a function expending a const char . Technically, this is an operator method. It was discovered that the Omnibar in Chrome went through many layers of translations between std::string and const char *, back and forth, such that there were approximately 25,000 string copies per keypress in the Omnibar. So my point is that even with a ton of resources writing good, efficient and performant C++ is still nontrivial. And that's really the point of Rust (well, one of them).
- steveklabnik 4y ago
  HN comments on this story: https://news.ycombinator.com/item?id=8704318 https://news.ycombinator.com/item?id=8704318
- fractalb 4y ago
  If all the dependent C libraries are replaced with C++ versions, then the no.of translations will become zero?
  - woodruffw 4y ago
    Nominally, yes. But conversions between C strings and `std::string` are just a small corner of the problem: C++ makes it very easy to accidentally call copying constructors and perform nontrivial copies when doing e.g. implicit argument conversion.

nikeee 4y ago

> The language, at least for now, is Rust. What are the alternatives in the context of Chromium development as a replacement for C++?

pjmlp 4y ago
https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... See "Using safer languages anywhere applicable".
- lordofgibbons 4y ago
  Interesting that Java, Swift, and Javascript are listed there but not Go. I wonder why
  - pjmlp 4y ago
    Because they are relevant on the context of Android, Apple OS, and ChromeOS respectively, as the main OS languages alongside C and C++.

bluejekyll 4y ago

> Rust is not yet available on all Chromium platforms (just Linux and Android for now) The beginning of this sentence didn’t surprise me, but the fact that it’s just Linux and Android did. Rust supports macOS and Windows really well, so I wonder what the gap is here? > Facilities and tooling in Rust are not as rich as other languages yet. Is this meant in the context of Chromium?

flohofwoe 4y ago
AFAIK it took years for the Chrome code base to allow a different C++ compiler than MSVC for the Windows build (e.g. Clang is now supported too). It's not surprising that they don't provide Rust support for all platforms right from the start.
cmrdporcupine 4y ago
The amount of things that have to happen for a modification to the build environment for a target is more than just that the tooling exists and is supported on those platforms. Picking just one piece: Consider that Chromium builds happen in a distributed build farm. There's multiple variants of this (goma, rbe). I'd imagine those systems would have to be modified to support the Rust toolchain for that target. And it looks like this work is built around making GN/ninja support Rust, just using cargo directly. So that's what they likely mean by "not as rich as other languages yet."

staticassertion 4y ago

I hope this works out. A memory safe browser would be a huge win for security.

brabel 4y ago
Are there many exploits caused by memory issues in Chromium?
- staticassertion 4y ago
  Yes, I believe literally every single 'in the wild' exploit has abused memory unsafety, as well as hundreds of vulnerabilities every year.
  - brabel 4y ago
    That's strange... if they'd written the code in a memory safe language, say, Java... there wouldn't be any vulnerability? I don't know... I see plenty of vulnerabilities in the Java world, no memory unsafety needed.
    - UncleMeat 4y ago
      Vulns exist in Java applications. Logic bugs can open all sorts of doors to exploitation. But empirically we observe that a huge portion of real vulnerabilities in applications written in C or C++ are memory errors. We've spent decades trying to get people to write C and C++ applications without these errors and utterly failed. A browser written in a memory safe language won't be free from vulns but it will be free from a huge class of recurring and very serious vulns.
    - staticassertion 4y ago
      The question was if the exploits were due to memory safety. The answer is, yes, 100% of them are due to memory safety. As for Java, quite a lot of the exploits against it (when it was a browser plugin) were in fact memory safety issues in the VM. But more recently what we see are serialization issues, which Rust also does not have.

blub 4y ago

I have a hard time imagining a more accidentally complex piece of software than a web browser written in C++ and in Rust. All the chaos of the so-called web standards, decades of accumulated C++ complexity and the eccentricity and burgeoning complexity of Rust on top. Getting assigned to such a project must be akin to punishment.

saagarjha 4y ago
In chaos some see order.
dblohm7 4y ago
Not really. That’s a typical workday for many Gecko developers. Some useful guidelines made it pretty straightforward: https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation

gitgud 4y ago

It's funny that it was created in Mozzila and first used in the [1] servo browser, and now is getting adopted by Mozzila's rival Chromium [1] https://en.m.wikipedia.org/wiki/Rust_(programming_language) https://en.m.wikipedia.org/wiki/Rust_(programming_language)