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

71–80 of 115 posts

Re: Experimenting with Rust in Chromium

#71

Post by ncmncm »

pornel wrote: post #64
ncmncm wrote: post #54

Earlier quoted context omitted.

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

So where are those mythical "good C++ programmers"? I keep hearing that if only you find them, your C++ will be secure. But so far nobody has found them. Not Google, not Microsoft, not Mozilla. Rust succeeds, because it does not rely on programmers writing bug-free code. Bad Rust code is not as dangerous as bad C++ code. BTW: deadlocks are not exploitable for RCE, and are quite easy to debug compared to data races an…

There is a very great deal of good C++ online. Google and Microsoft are handicapped by their need to hire in huge numbers, and must take who they can get.

Re: Experimenting with Rust in Chromium

#72

Post by jeffbee »

jcelerier wrote: post #69
tialaramex wrote: post #42

Earlier quoted context omitted.

> the ancient past before the STL was fully standardized Specifically the "ancient past" here is prior to C++ 11 when C++ decided now it wanted to actually define how its string type works because C++ 98 and C++ 03 strings are both even more dangerous than most things are in C++ and had to be put out of their misery.

> because C++ 98 and C++ 03 strings are both even more dangerous ... how so ? they were just CoW which is actually I think the better choice most of the time... now there are copies all over the place

CoW strings with atomic reference counting was definitely the wrong choice for a multi-core universe. The performance penalty is way too high. If you need that semantic there are other ways to get it.

Re: Experimenting with Rust in Chromium

#73

Post by mwcampbell »

imron wrote: post #23
mseepgood wrote: post #18

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…

This discussion is making me wonder if windows-rs [1], the crate with official Rust bindings for all Windows APIs, is doing something that's not idiomatic Rust. Specifically, for any Windows API function that takes a UTF-16 string as a parameter, the signature for that parameter is something like "impl IntoParam". The crate then implements that trait for String and &str, so you can pass a normal Rust UTF-8 string (even a string literal), and it'll be automatically converted to a freshly-allocated, null-terminated UTF-16 string (which gets freed after the function call). That seems like it could lead to the same thoughtless inefficiency as in the story about the Chrome omnibox.

[1]: https://github.com/microsoft/windows-rs

Re: Experimenting with Rust in Chromium

#74

Post by jeffbee »

woodruffw wrote: post #14
fractalb wrote: post #12

Earlier quoted context omitted.

If all the dependent C libraries are replaced with C++ versions, then the no.of translations will become zero?

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.

Yep, another serious performance problem (also at google, not in chromium) was caused by inaccurate declaration of lambda arguments in an STL algorithm call … ie std::something(begin, end, [](std::pair foobar) -> bool {}). The actual type (iterating over an unordered map, I believe) would have been const foo, but the compiler correctly concluded it could implicitly create a pair of foo,bar by copy from pair of const foo,bar. These were the days before such arguments could be declared “auto” which would have avoided the problem.

You have to think very very carefully about every line and character in C++ to figure out what it’s doing. Sometimes the easiest way to review it is to compile it and read the assembly.

Re: Experimenting with Rust in Chromium

#75

Post by andreidd »

hoseja wrote: post #38
imron wrote: post #23

Earlier quoted context omitted.

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…

psst... std::string_view

And then someone will convert a std::string_view to a const char* and things will explode...

Re: Experimenting with Rust in Chromium

#76

Post by [deleted] »

ncmncm wrote: post #54
blub wrote: post #50

Earlier quoted context omitted.

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

[deleted]

Re: Experimenting with Rust in Chromium

#78

Post by imron »

cmrdporcupine wrote: post #52
imron wrote: post #40

Earlier quoted context omitted.

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 e…

The point is not that c++ can't do this (I also have code that does this dating back over 10 years), it's that despite having code to do string_view/string_piece, Chromium was still performing 25,000 allocations per keystroke in its Omnibox because c++ has other common ways to represent "constant string owned by someone else", and there are hidden performance issues that will trip up even experienced programmers when mixing these ways incorrectly.

Despite having better options available (either in the standard library or custom code), the less optimal ways still get used.

Rust had the benefit of learning from c++'s mistakes and separated the concepts of owned vs unowned strings in to separate types with explicit conversions required whenever an allocation would occur. This was baked in to the language from the beginning and so you don't get a mix of different types in signatures to convey the concept of pointing to a slice of a string owned by someone else, you just have &str.

Even if you get fancy with your interface and do things like AsRef, there's still no concern about implicit or hidden allocations. Any time you need to own the memory (either for yourself or to pass in to another function) you need to do so explicitly and you end up with a different type (much to the chagrin and confusion of newcomers to the language).

C++ is trying to correct its mistakes also, but not everyone can use those latest features and even if they can, the mistakes still have to be left in for compatibility reasons.

Re: Experimenting with Rust in Chromium

#79

Post by yjftsjthsd-h »

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.

Oh, that's easy; all you have to do is argue that it wasn't a representative sample. Just because 70% of security problems in Chromium are memory-safety problems doesn't mean that arbitrary project X has the same proportion or risks. Chromium is a very specific kind of application (network client that almost exclusively talks to untrusted servers, does media decoding, large, runs as an application, long-running), so it's plausible that its issues are unique.

However, it gets a lot harder to argue that it's just Chromium when Microsoft found the same thing: https://www.zdnet.com/article/microsoft-70-percent-of-all-se... At that point, the strongest argument shifts from "Chromium is the outlier" to "my code is the outlier". And that's... possible to defend (ex. the OpenBSD folks have a track record that says they can write safe C), but certainly harder.

Re: Experimenting with Rust in Chromium

#80

Post by dblohm7 »

blub wrote: post #47

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.

Not really. That’s a typical workday for many Gecko developers.

Some useful guidelines made it pretty straightforward:

https://wiki.mozilla.org/Oxidation

Post reply on HN