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

Rust and C++ Interoperability in Chrome

chromium.org

Post reply on HN
Print view View original

41–50 of 150 posts

Re: Rust and C++ Interoperability in Chrome

#41

Post by webkike »

xxpor wrote: post #28
Paul-ish wrote: post #25

Back when I was an intern at Mozilla it was a real pain (in my opinion) to call between C++ and Rust. This was before bindgen and cbindgen, and certainly CXX. Eg if you have a heap allocated thing that is passed between Rust and C++, who frees it? I ended up hacking something together, but it didn't feel right.

>if you have a heap allocated thing that is passed between Rust and C++, who frees it? Isn't this an issue regardless? Forget crossing the rust/c++ boundary, lets say you pass something to another class in c++, you need to have a contract of who frees what when, right? Maybe I'm not understanding the issue.

There are some things that make this better, such as returning pointer types and not returning raw pointers. Returning raw pointers usually means that another function will delete them. I very rarely see pointers handed back from functions being freed caller side

Re: Rust and C++ Interoperability in Chrome

#42

Post by coder543 »

lalaithion wrote: post #39
coder543 wrote: post #16

Earlier quoted context omitted.

Really, your text macro substitution is missing the broader point. Hiding the word "unsafe" doesn't make it any less unsafe. The Rust compiler can't guarantee that the C++ code being called doesn't have use-after-free bugs or buffer overflows. The Rust compiler can't guarantee that pointers being returned from C++ code aren't just wild pointers that point in the middle of nowhere. The Rust compiler can't guarantee th…

I disagree; All of the things you say about C++ code also apply to unsafe Rust code. There's an unsafe keyword that allows using that unsafe code, and when you use it, you are asserting to the compiler that "I promise this code is actually being used in a safe way". All this document says is that the C++/Rust boundary should be considered another place where you are asserting "I promise this code is actually being us…

> All of the things you say about C++ code also apply to unsafe Rust code.

Which is why unsafe is considered a code smell, and why people in the Rust community get upset when unsafe is used unnecessarily. That's why some people might find it controversial to hide the unsafety of the C++ code being used here. I've used Rust professionally for years, and I don't remember ever having to write any unsafe code in a professional context apart from FFI, and even then... the glue code to wrap around that unsafe FFI was very strictly written to make things as comfortable as possible for the FFI code and minimize the chance of bad things happening on the other side of the FFI barrier.

However, even then, your statement is not entirely correct. Unsafe Rust is extremely similar to safe Rust, enforcing the vast majority of safety requirements automatically. Unsafe code is very limited in what bad things it can do compared to C++ code.

https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsa...

- Dereference a raw pointer

- Call an unsafe function or method

- Access or modify a mutable static variable

- Implement an unsafe trait

- Access fields of unions

Those are the only things unsafe Rust can do that safe Rust can't. It doesn't turn off the borrow checker or anything else. There are a lot of mistakes that can be made in normal C++ code that you can't make in regular, safe Rust.

> All this document says is that the C++/Rust boundary should be considered another place where you are asserting "I promise this code is actually being used in a safe way".

The problem is that C++ compilers are much less capable of enforcing safety (inherently, due to legacy design decisions and backwards compatibility), so you often want a layer of glue code that only allows you to use C++ code in ways that are known to be safe, not just any arbitrary way that the function might be callable.

I already said I agree Chromium's team seems to be making the right call for this specific situation. It's not the right call most of the time. C++ code isn't fungible as being "just as good" as safe Rust code. The unsafety needs to be obvious, just like it is with unsafe Rust, so that you can recognize that the external C++ code (or unsafe Rsut) is a loaded footgun, and to treat it with appropriate care.

To be clear: Rust isn't a perfect language, and you can get the vast majority of the safety benefits by using almost any garbage collected language. What makes Rust awesome is that you can bring the memory safety of garbage collected languages into the realm of consistent performance requirements that previously was inhabited mostly by C and C++. Rust is a nice language, but so are a lot of other languages.

Re: Rust and C++ Interoperability in Chrome

#43

Post by oscargrouch »

kllrnohj wrote: post #40
oscargrouch wrote: post #37

Earlier quoted context omitted.

That is the problem with default narratives, they dont adapt well to every case. Chromium codebase is a massive codebase. It works, its efficient and fast, its sophisticated and complex, its well tested, had all sort of bugs that was taken out of them. Its really well written C++ code with modern ownership semantics. So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems yo…

> So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems you really face. https://bugs.chromium.org/p/project-zero/issues/list?q=produ... This year alone saw 2 issues from Project Zero in Chrome that would have been prevented by Rust - both OOB accesses, one with a helping of data racing. Chromium is an incredibly security-sensitive piece of software, and that really is an…

I have no doubt that Rust could save some sort of bugs. If you read all the comment i´ve made, you will see that we are talking about a massive codebase already coded in C++.

Giving the time it is alive, all the engineering hours, investiments, tools, etc.. most of the bugs that Rust could have prevented right on the beggining are already covered (Chrome also uses fuzzers and static analysis tools to automate C++ code)

> This year alone saw 2 issues from Project Zero in Chrome that would have been prevented by Rust

Thanks for making my point even clearer. If you really knew the size of the codebase, having only 2 issues on Project Zero is kind of a compliment to Chrome.

By the way, it was yesterday, that i´ve saw a research with fuzzers applied in C, C++ and Rust codebases.

In that research, Rust had the same overall count of bugs and even some 'zero day' sort of ones not any different from C++ and C codebases (maybe just better than the C one).

Its a pitty i can find where it is (I´ve saw it on Twitter, but its pretty recent).

> Chromium is an incredibly security-sensitive piece of software, and that really is an excellent fit for Rust. It's not a boogeyman argument and the Chromium team themselves are the ones pursuing it, it's not being forced on them.

A Chrome started from zero in 2020? probably.. but thats not the reality here. Millions of lines of C++ code, and its not just a matter of language, but the knowledge and people with the know-how to write those pieces..

Thats why im saying is not worth it..

Re: Rust and C++ Interoperability in Chrome

#44

Post by joshuamorton »

oscargrouch wrote: post #37
nilkn wrote: post #34

Earlier quoted context omitted.

I doubt the point is to offer people a playground but rather to find a way to write new code in a language that is memory safe by default. Browsers are notoriously plagued by bugs related to memory safety so there’s quite a lot of motivation for at least considering this path.

That is the problem with default narratives, they dont adapt well to every case. Chromium codebase is a massive codebase. It works, its efficient and fast, its sophisticated and complex, its well tested, had all sort of bugs that was taken out of them. Its really well written C++ code with modern ownership semantics. So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems yo…

> So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems you really face.

To elaborate on the other commenter, the majority of bugs found in chromium are bugs that rust would avoid (memory safety issues that rust makes ~impossible).

Re: Rust and C++ Interoperability in Chrome

#45

Post by foota »

lalaithion wrote: post #39
coder543 wrote: post #16

Earlier quoted context omitted.

Really, your text macro substitution is missing the broader point. Hiding the word "unsafe" doesn't make it any less unsafe. The Rust compiler can't guarantee that the C++ code being called doesn't have use-after-free bugs or buffer overflows. The Rust compiler can't guarantee that pointers being returned from C++ code aren't just wild pointers that point in the middle of nowhere. The Rust compiler can't guarantee th…

I disagree; All of the things you say about C++ code also apply to unsafe Rust code. There's an unsafe keyword that allows using that unsafe code, and when you use it, you are asserting to the compiler that "I promise this code is actually being used in a safe way". All this document says is that the C++/Rust boundary should be considered another place where you are asserting "I promise this code is actually being us…

I think the issue is that rust unsafe means "does something sketchy" whereas even perfectly safe C++ would have to be annotated unsafe.

Re: Rust and C++ Interoperability in Chrome

#46

Post by Matthias247 »

webkike wrote: post #41
xxpor wrote: post #28

Earlier quoted context omitted.

>if you have a heap allocated thing that is passed between Rust and C++, who frees it? Isn't this an issue regardless? Forget crossing the rust/c++ boundary, lets say you pass something to another class in c++, you need to have a contract of who frees what when, right? Maybe I'm not understanding the issue.

There are some things that make this better, such as returning pointer types and not returning raw pointers. Returning raw pointers usually means that another function will delete them. I very rarely see pointers handed back from functions being freed caller side

Do you mean references instead of pointers? I'm not familiar of a difference between pointers and raw pointers in C or C++.

C++ allows to be more clear: unique_ptrs allow to move ownership, references mean this is definitely not owned, and the remaining questions are around normal pointers.

With pure C there is however zero distinction. A pointer can mean ownership is transferred, it is meant to be a reference, it could be a static reference to something in constant memory, etc.

Re: Rust and C++ Interoperability in Chrome

#47

Post by edflsafoiewq »

xxpor wrote: post #28
Paul-ish wrote: post #25

Back when I was an intern at Mozilla it was a real pain (in my opinion) to call between C++ and Rust. This was before bindgen and cbindgen, and certainly CXX. Eg if you have a heap allocated thing that is passed between Rust and C++, who frees it? I ended up hacking something together, but it didn't feel right.

>if you have a heap allocated thing that is passed between Rust and C++, who frees it? Isn't this an issue regardless? Forget crossing the rust/c++ boundary, lets say you pass something to another class in c++, you need to have a contract of who frees what when, right? Maybe I'm not understanding the issue.

RAII usually handles all that.

Re: Rust and C++ Interoperability in Chrome

#48

Post by outworlder »

eggsnbacon1 wrote: post #10

Do they really need to access thousands of C++ API calls from Rust? Doesn't this defeat the purpose of writing safe code in Rust? This smells of "not invented here" which applies to Google projects pretty often. They should focus on integrating Rust in portions of the API instead of exposing a gigantic unsafe API surface, essentially making all their code unsafe. Unless the Chrome codebase is really such a mess that…

> Do they really need to access thousands of C++ API calls from Rust?

Yes. It's turtles all the way down. Applying this line of thought to its logical conclusion, it wouldn't be worth it until we have written the OS itself and all firmware in Rust.

Re: Rust and C++ Interoperability in Chrome

#49

Post by oscargrouch »

joshuamorton wrote: post #44
oscargrouch wrote: post #37

Earlier quoted context omitted.

That is the problem with default narratives, they dont adapt well to every case. Chromium codebase is a massive codebase. It works, its efficient and fast, its sophisticated and complex, its well tested, had all sort of bugs that was taken out of them. Its really well written C++ code with modern ownership semantics. So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems yo…

> So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems you really face. To elaborate on the other commenter, the majority of bugs found in chromium are bugs that rust would avoid (memory safety issues that rust makes ~impossible).

If it was written from the start in Rust, i have no doubts. But thats not the reality being faced here.

Right now the Chromium codebase have less bugs than if it was written in Rust, because of how many hours and efforts that were spent on the codebase to make it work smoothly.

Also the particular engineers with particular know-hows work with a particular tool. Its not easy to find them especially if you are forcing to use a new language in a giving project. It will take years and even decades to have the same quality people you already have in C and/or C++ in Rust.

So it will take time to have an engineer that can make, lets say, a multi-process compositor in Rust. What about many people with that particular special knowledge that take years to be good at.

So in real life its not just a matter of a language being a better fit. Theres a lot of other vectors to take into account.

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Re: Rust and C++ Interoperability in Chrome

#50

Post by mrich »

oscargrouch wrote: post #43
kllrnohj wrote: post #40

Earlier quoted context omitted.

> So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems you really face. https://bugs.chromium.org/p/project-zero/issues/list?q=produ... This year alone saw 2 issues from Project Zero in Chrome that would have been prevented by Rust - both OOB accesses, one with a helping of data racing. Chromium is an incredibly security-sensitive piece of software, and that really is an…

I have no doubt that Rust could save some sort of bugs. If you read all the comment i´ve made, you will see that we are talking about a massive codebase already coded in C++. Giving the time it is alive, all the engineering hours, investiments, tools, etc.. most of the bugs that Rust could have prevented right on the beggining are already covered (Chrome also uses fuzzers and static analysis tools to automate C++ cod…

You also have to consider the huge investment that testing takes. Not only person days spent writing tests, but also infrastructure costs for running fuzzers, huge test suites and so on. And although the code base is already there and tested, it constantly changes, so there is no way to just incrementally test it. At some point you have to make some advances in the way you approach software development, not everything can be handled by brute force.
Post reply on HN