Live data from Hacker News

Experimenting with Rust in Chromium

chromium.googlesource.com

21–30 of 115 posts

Re: Experimenting with Rust in Chromium

#21
post #10

Earlier quoted context omitted.

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…

How would Rust help here? Isn't it famous for having too many string types?

In C++ when I see `DoX(y)` I have to worry every time about temporary lifetimes, copy vs move operator, and a bunch of other things that are easy to miss during code review. It is so easy to accidentally copy large strings around many times in a performance critical loop.

Rust makes all of that easier to see during code review. It is very explicit about these things.

I'm a Google employee working on chromium and chromeOS and have been asking internally about rust support for over a year now, so it's exciting that it's making progress.

Re: Experimenting with Rust in Chromium

#23
post #10

Earlier quoted context omitted.

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…

How would Rust help here? Isn't it famous for having too many string types?

It's the 'too many string types' that helps.

With C++, if you have char*'s (because you don't need to own the memory) and you pass it to a function that takes a const std::string& (because it also doesn't want to own the memory), then there will still be an implicit conversion to a temporary std::string (involving an allocation) despite neither the caller or the callee needing to own any memory.

With Rust, if you have a &str (because you don't need to own the memory) and you pass it to any function that takes a String (or even the unidiomatic &String), then you will get a compile error. There won't be any implicit conversion of types and therefore no implicit allocation. If you really want to pass it, you need to explicitly convert it, making the cost of the allocation explicit.

Rust's "too many strings" model says "there are many different ways in which you can use string-like objects, each with their own performance tradeoffs. Know which one you want to use in your code or I won't compile".

Re: Experimenting with Rust in Chromium

#25
post #24

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

Are there many exploits caused by memory issues in Chromium?

Yes, I believe literally every single 'in the wild' exploit has abused memory unsafety, as well as hundreds of vulnerabilities every year.

Re: Experimenting with Rust in Chromium

#26
post #24

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

Are there many exploits caused by memory issues in Chromium?

About 70% of all exploits: https://www.chromium.org/Home/chromium-security/memory-safet...

Re: Experimenting with Rust in Chromium

#27
post #26
post #24

Earlier quoted context omitted.

Are there many exploits caused by memory issues in Chromium?

About 70% of all exploits: https://www.chromium.org/Home/chromium-security/memory-safet...

Just to clarify, exploit generally refers to software that takes advantage of vulnerabilities, vulnerabilities are the flaws themselves. As in, one writes code to "exploit" a "vulnerability".

70% of all vulnerabilities reported to them are memory safety issues. To my knowledge, 100% of exploits against Chrome in the wild leverage memory unsafety.

Re: Experimenting with Rust in Chromium

#28
post #7

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

For me, the fact that the Linux project has decided that Rust will be included in the kernel was the point Rust has become a success. It's pretty clear at this point that Rust will be around for decades and start to replace the well established C space.

> the Linux project has decided that Rust will be included in the kernel

Isn't this a bit oversimplified? IIRC the Rust support was only started as an option for writing device drivers in Rust, not actual kernel code, and even this relatively simple use case looks like a herculean effort which required changes to feed back into Rust - which is a good thing of course, but currently it looks like the Rust ecosystem benefits more from that project than the Linux ecosystem ;)

Re: Experimenting with Rust in Chromium

#29
post #26

Earlier quoted context omitted.

About 70% of all exploits: https://www.chromium.org/Home/chromium-security/memory-safet...

Just to clarify, exploit generally refers to software that takes advantage of vulnerabilities, vulnerabilities are the flaws themselves. As in, one writes code to "exploit" a "vulnerability". 70% of all vulnerabilities reported to them are memory safety issues. To my knowledge, 100% of exploits against Chrome in the wild leverage memory unsafety.

Good point!

Re: Experimenting with Rust in Chromium

#30
post #23

Earlier quoted context omitted.

How would Rust help here? Isn't it famous for having too many string types?

It's the 'too many string types' that helps. With C++, if you have char*'s (because you don't need to own the memory) and you pass it to a function that takes a const std::string& (because it also doesn't want to own the memory), then there will still be an implicit conversion to a temporary std::string (involving an allocation) despite neither the caller or the callee needing to own any memory. With Rust, if you hav…

It would most likely suffer from similar problems when interacting with the C and C++ APIs in the rest of Chrome though (e.g. what to do if you have a Rust String, but the other side wants a const ref to a C++ std::string).
Post reply on HN