3 ms·

Replacing small components like a single codec or parser wouldn't require anywhere near what Google is asking for in that document. I'm not saying to replace V8

Replacing small components like a single codec or parser wouldn't require anywhere near what Google is asking for in that document. I'm not saying to replace V8 with Rust. > but now you've lost the memory safety advantages of rust No you haven't.

jsnell 5y ago
But replacing small isolated components is not a very interesting option. It means you're paying the costs of a multi-language codebase, in terms of build complexity, having to duplicate infrastructure, and siloing of developers. In return you'll only be getting limited benefits from it, since the usage will only be restricted to few cases and a full migration can never happen. Every single decision on what language to use for a component in becomes a hard to reverse ("will this component always remain a leaf node with a really simple interface?"), slowing down decision making and ossifying the architecture.
- staticassertion 5y ago
  > But replacing small isolated components is not a very interesting option. I seriously disagree. Again, I mentioned things like JSON parsing which deal with untrusted data but also are too performance sensitive to move OOP. Chromium's own security guidelines explicitly states that you should never mix memory unsafe code with inprocess code with untrusted input. I strongly believe you'd get significant returns by incrementally replacing components like that with Rust. > Every single decision on what language to use for a component in becomes a hard to reverse This is purely an organizational issue in my opinion. If the decision were made to follow the guidelines their security team has laid out, there is no question or slow-down. The guidelines are very competent and clear; memory unsafe, untrusted input, in-process - pick one at most.
  - esprehn 5y ago
    Do you have examples of exploits in the non-sandboxed JSON parser? That code doesn't appear to have any security/memory safety related fixes in the last 2 years: https://chromium.googlesource.com/chromium/src.git/+log/refs/heads/main/base/json https://chromium.googlesource.com/chromium/src.git/+log/refs... It's not clear what the return would be from rewriting that code in rust.
    - staticassertion 5y ago
      JSON is just a straightforward example because it's easy to understand how it falls into Chromium's threat model. Feel free to replace it with font parsing, audio/video codecs, etc, and you'll find thousands of relevant vulns.
- pcwalton 5y ago
  Being able to add new features without greatly expanding the attack surface is important for security. When new components of Firefox have been written in Rust, there have empirically been far fewer security problems to shake out than when they've been written in C++. Is Rust of more limited benefit when it's only being used for certain components as opposed to the entire codebase? Sure. But is it still worth using for new code? Frequently, yes.

jsnell 5y ago

But replacing small isolated components is not a very interesting option. It means you're paying the costs of a multi-language codebase, in terms of build complexity, having to duplicate infrastructure, and siloing of developers. In return you'll only be getting limited benefits from it, since the usage will only be restricted to few cases and a full migration can never happen. Every single decision on what language to use for a component in becomes a hard to reverse ("will this component always remain a leaf node with a really simple interface?"), slowing down decision making and ossifying the architecture.

staticassertion 5y ago
> But replacing small isolated components is not a very interesting option. I seriously disagree. Again, I mentioned things like JSON parsing which deal with untrusted data but also are too performance sensitive to move OOP. Chromium's own security guidelines explicitly states that you should never mix memory unsafe code with inprocess code with untrusted input. I strongly believe you'd get significant returns by incrementally replacing components like that with Rust. > Every single decision on what language to use for a component in becomes a hard to reverse This is purely an organizational issue in my opinion. If the decision were made to follow the guidelines their security team has laid out, there is no question or slow-down. The guidelines are very competent and clear; memory unsafe, untrusted input, in-process - pick one at most.
- esprehn 5y ago
  Do you have examples of exploits in the non-sandboxed JSON parser? That code doesn't appear to have any security/memory safety related fixes in the last 2 years: https://chromium.googlesource.com/chromium/src.git/+log/refs/heads/main/base/json https://chromium.googlesource.com/chromium/src.git/+log/refs... It's not clear what the return would be from rewriting that code in rust.
  - staticassertion 5y ago
    JSON is just a straightforward example because it's easy to understand how it falls into Chromium's threat model. Feel free to replace it with font parsing, audio/video codecs, etc, and you'll find thousands of relevant vulns.
pcwalton 5y ago
Being able to add new features without greatly expanding the attack surface is important for security. When new components of Firefox have been written in Rust, there have empirically been far fewer security problems to shake out than when they've been written in C++. Is Rust of more limited benefit when it's only being used for certain components as opposed to the entire codebase? Sure. But is it still worth using for new code? Frequently, yes.