Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Experimenting with Rust in Chromium

chromium.googlesource.com

Post reply on HN
Print view View original

51–60 of 115 posts

Re: Experimenting with Rust in Chromium

#51

Post by comment500 »

selfmodruntime wrote: post #46
staticassertion wrote: post #27

Earlier quoted context omitted.

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.

How anyone can read a survey like this and still argue that the benefits of Rust (or any language with the ownership model) don't outweigh the risks / negative aspects is beyond me.

One caveat here is that many of the vulns used in the wild are in V8 and related to JIT code generation. Unfortunately rewriting in Rust can't really help with this.

Re: Experimenting with Rust in Chromium

#52

Post by cmrdporcupine »

imron wrote: post #40
hoseja wrote: post #38

Earlier quoted context omitted.

psst... std::string_view

A step in the right direction if you have a compiler with c++17 support. Note: chrome only supported c++17 features in Dec 2021 [0], and whether std::string_view is allowed to be used is still 'to be determined'. 0: https://chromium.googlesource.com/chromium/src/+/HEAD/styleg...

A variant of what is becoming string_view in the standard has existed within Google's codebase(s) for years. I don't recall using it much in Chromium when I worked in there, but it's all over Google3 and is now in absl (Google's open sourcing of some of its base c++ components).

Chromium has "string_piece": https://chromium.googlesource.com/chromium/src/base/+/refs/h... which is at least 9 years old (was moved from elsewhere in the repo into base/ then)

Re: Experimenting with Rust in Chromium

#53

Post by cmrdporcupine »

bluejekyll wrote: post #17

> 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?

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."

Re: Experimenting with Rust in Chromium

#54

Post by ncmncm »

blub wrote: post #50
cletus wrote: 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…

Based on the code changes made at that time, it seemed that Chrome developers didn’t know how to write performant C++ code. Those were not difficult to understand C++ features either, but basic ones which were very well known by then. I remember reading Bulka & Mayhew’s Efficient C++ (published in 2000) which mentioned the importance of avoiding copies, calling reserve and many other techniques. So your point is wron…

Yes.

In two words, Google programmers are, as a rule, vastly overrated. They can maybe rope in 100,000 cores on one query, but nothing in their recruiting selects for good coding habits.

Anybody coding C++ in this day'n'age and getting use-after faults needs to go to the back of the line. They will certainly succeed in writing new Rust code that is as bad as their old C++ code. (Note: deadlocks are officially "safe".)

Recently Google made a big push to change the std::string constructor from a null char* to yield the empty string, instead of honestly segfaulting. That failed. They had a half-baked (and hellish, for users) async/await design they tried to put up as worth delaying the whole feature into 2023. That failed.

Re: Experimenting with Rust in Chromium

#55

Post by ncmncm »

imron wrote: post #39
gary_0 wrote: post #36

Earlier quoted context omitted.

I'm not sure if this is what OP was referring to, but in the ancient past before the STL was fully standardized, some implementations had an `operator const char*` in std::string to allow implicit conversions.

Perhaps, but in the in the ancient past before STL was standardized, Chrome didn't exist. 10 years ago (when the parent mentioned they were still at Google) c++11 was already out.

Ja, they have no excuse. They mostly just don't care. And why should they? Google cares nothing for them.

Re: Experimenting with Rust in Chromium

#56

Post by southerntofu »

imron wrote: post #39
gary_0 wrote: post #36

Earlier quoted context omitted.

I'm not sure if this is what OP was referring to, but in the ancient past before the STL was fully standardized, some implementations had an `operator const char*` in std::string to allow implicit conversions.

Perhaps, but in the in the ancient past before STL was standardized, Chrome didn't exist. 10 years ago (when the parent mentioned they were still at Google) c++11 was already out.

Ten years ago was 2012. C++11 came out in 2011. Do you believe a big codebase like Chrome would be converted to C++11 less than one year after the spec was published? I find that unlikely but i never worked on such a big codebase so i wouldn't know.

Re: Experimenting with Rust in Chromium

#57

Post by CJefferson »

southerntofu wrote: post #56
imron wrote: post #39

Earlier quoted context omitted.

Perhaps, but in the in the ancient past before STL was standardized, Chrome didn't exist. 10 years ago (when the parent mentioned they were still at Google) c++11 was already out.

Ten years ago was 2012. C++11 came out in 2011. Do you believe a big codebase like Chrome would be converted to C++11 less than one year after the spec was published? I find that unlikely but i never worked on such a big codebase so i wouldn't know.

The STL was mostly standardised in C++98, 1998. There were additions in C++03 and C++11, but nothing like removing this type of overload.

Long running systems were still using pre-standardisation libraries for string up to 2012 however, so you may well have come across such projects.

Re: Experimenting with Rust in Chromium

#58

Post by brabel »

staticassertion wrote: post #25
brabel wrote: post #24

Earlier quoted context omitted.

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.

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.

Re: Experimenting with Rust in Chromium

#59

Post by tialaramex »

imron wrote: post #39
gary_0 wrote: post #36

Earlier quoted context omitted.

I'm not sure if this is what OP was referring to, but in the ancient past before the STL was fully standardized, some implementations had an `operator const char*` in std::string to allow implicit conversions.

Perhaps, but in the in the ancient past before STL was standardized, Chrome didn't exist. 10 years ago (when the parent mentioned they were still at Google) c++11 was already out.

While it's true that the Standard Template Library is truly a "long time" ago, being a 1990s project, the poster's phrase "before STL was standardized" actually refers to C++ 98 and C++ 03 where the C++ standards don't specify std::string internals.

Originally C++ doesn't have a string type, the C++ 98 standard does standardize a string type but it's only loosely specified. Most implementations do something "clever" which it turns out is a bad idea (this is a recurring theme in C++. Only in C++ 11 does the standard say OK, we'll prescribe how the string class actually works, making it more complicated but hopefully avoiding the worst problems.

Chrome was launched in 2008, and much of its internal structure was far older having incorporated work by Mozilla and Apple.

Re: Experimenting with Rust in Chromium

#60

Post by tialaramex »

CJefferson wrote: post #57
southerntofu wrote: post #56

Earlier quoted context omitted.

Ten years ago was 2012. C++11 came out in 2011. Do you believe a big codebase like Chrome would be converted to C++11 less than one year after the spec was published? I find that unlikely but i never worked on such a big codebase so i wouldn't know.

The STL was mostly standardised in C++98, 1998. There were additions in C++03 and C++11, but nothing like removing this type of overload. Long running systems were still using pre-standardisation libraries for string up to 2012 however, so you may well have come across such projects.

> nothing like removing this type of overload.

Bzzt. C++ 11 completely overhauls how std::string is defined.

Post reply on HN