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

81–90 of 150 posts

Re: Rust and C++ Interoperability in Chrome

#81

Post by coder543 »

jcranmer wrote: post #58
coder543 wrote: post #42

Earlier quoted context omitted.

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

> 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. You can do serious damage with those things though. One tactic I have done is to expand the lifetime of a reference by laundering it through a raw pointer, since the function to convert a raw pointer to a reference allows you to choose any lifetime you want.

Yes, but good luck getting that through any form of code review. The unsafe block and the raw pointers or the call to transmute make it pretty obvious that something fishy is going on that’s worth reading carefully. ¯\_/(ツ)\_/¯

Unlike C or C++, where it can sometimes be harder to tell what the lifetime of something should be, or whether you’re extending the lifetime of a reference beyond the point that it is safe.

Unsafe definitely gives you loaded footguns... which for the umpteenth time is why it is considered a code smell. Sometimes you have to write smelly code, but it’s something to be avoided.

Re: Rust and C++ Interoperability in Chrome

#82

Post by roca »

oscargrouch wrote: post #54
mrich wrote: post #50

Earlier quoted context omitted.

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

It would cost much more to rewrite in Rust. Again thats why im saying that if the project would start now in 2020, all of those would be pretty good points. Right now is too late for that. As another example, you can get just the V8 VM for instance. For start, with the ammount of solid code out there it would be nuts to talk over a rewrite.. Now imagine if we add to that, that the knowledge on JIT compilers is so dif…

If you care about security, it is much easier to write non-exploitable code in Rust than in C++, and you can hire accordingly.

Actually, the people who are really experienced at writing secure code in C++ understand that they can't do it reliably, and an increasing number of them (like me) would much rather write Rust code instead for that reason. So for secure code the hiring advantage is tilting away from C++ towards Rust.

Re: Rust and C++ Interoperability in Chrome

#83

Post by bialpio »

rightbyte wrote: post #35
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.

Surely C++ exceptions and destructors has to be the main issue for interoperation? I've done to many C++ wrappers with C linkage of C++ libs to call from C, that convert exceptions to error codes and free_obj() wrappers to run destructors.

Chromium does not allow using exceptions, so it may not be that important issue to solve.

Re: Rust and C++ Interoperability in Chrome

#84

Post by rkangel »

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…

This is the right way of viewing it. What unsafe means to a person is fairly irrelevant. What it means to the compiler is 'please insert this code where I have checked the guarantees rather than you'.

Doing this a lot in pure Rust is a bad smell because you usually have other options and you're opening yourself up to risk. In this case the code exists and you already own all that risk so it's perfectly reasonable.

Re: Rust and C++ Interoperability in Chrome

#85

Post by [deleted] »

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…

[deleted]

Re: Rust and C++ Interoperability in Chrome

#86

Post by [deleted] »

kbenson wrote: post #70

> No need for the “unsafe” keyword unless something is known to be less safe than normal C++. > For a Rustacean, this is controversial - all C++ is unsafe! Isn't this just a fundamental misunderstanding of what unsafe really means, and as such a nonsense goal that doesn't gain anything? Unsafe is a Rust language definition, and defines whether the rust compiler can vouch for the safety of some code. As such, calling…

[deleted]

Re: Rust and C++ Interoperability in Chrome

#87

Post by codeflo »

kbenson wrote: post #70

> No need for the “unsafe” keyword unless something is known to be less safe than normal C++. > For a Rustacean, this is controversial - all C++ is unsafe! Isn't this just a fundamental misunderstanding of what unsafe really means, and as such a nonsense goal that doesn't gain anything? Unsafe is a Rust language definition, and defines whether the rust compiler can vouch for the safety of some code. As such, calling…

The usual understanding is that an unsafe function is any function that can, if passed the wrong arguments, cause Undefined Behavior. A lot of Rust’s std and library ecosystem provides safe wrappers around underlying unsafe C APIs, by cleverly using borrow semantics and performing additional runtime checks. The bar for safety is lower than you might expect, for example, crashing with a “panic” in case of an error is completely fine, that’s not considered unsafe.

Presumably, the C++ wrappers suggested here would not even be safe in that sense. They would use a lot of pointers, and cause UB if passed the wrong one. The article argues that using unsafe correctly is impractical for Chromium because basically every Rust function would have to be marked unsafe to call into these raw C++ APIs.

Whether that’s the right call, I don’t know. I see the practical argument, but I also think that a lot of common Rust idioms, especially around memory management, depend on these safety guarantees. For example, field destruction order in Rust is weird and you often don’t control it as carefully as you would in C++. That’s usually fine in normal Rust code, but might not be if lots of marked-as-safe-but-actually-unsafe code is flying around.

Re: Rust and C++ Interoperability in Chrome

#88

Post by rvz »

roca wrote: post #82
oscargrouch wrote: post #54

Earlier quoted context omitted.

It would cost much more to rewrite in Rust. Again thats why im saying that if the project would start now in 2020, all of those would be pretty good points. Right now is too late for that. As another example, you can get just the V8 VM for instance. For start, with the ammount of solid code out there it would be nuts to talk over a rewrite.. Now imagine if we add to that, that the knowledge on JIT compilers is so dif…

If you care about security, it is much easier to write non-exploitable code in Rust than in C++, and you can hire accordingly. Actually, the people who are really experienced at writing secure code in C++ understand that they can't do it reliably, and an increasing number of them (like me) would much rather write Rust code instead for that reason. So for secure code the hiring advantage is tilting away from C++ towar…

Yet once the Chromium team goes down that Rust to C++ FFI route, they will encounter the same old bugs outlined in this paper. [0] They might as well fork Servo and create their own engine from that, but even that is still a prototype worked on for years with zero C++ at least.

It's too early to see how the Chromium team will begin to work on this given it's only a plan, but maybe the unsafety and security issues are enough motivation to actually use Rust to C++ interop or a rewrite. But once again, this has been tried by some other projects and by just looking at the effort of a rewrite, they later concluded that it is not worth it. [1] [2]

Even better, just improve Servo instead. But I guess they would rather create their own fork, just like they did with WebKit.

[0] https://arxiv.org/pdf/2003.03296.pdf

[1] https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the-mesh-g...

[2] http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...

Re: Rust and C++ Interoperability in Chrome

#89

Post by steveklabnik »

codeflo wrote: post #87
kbenson wrote: post #70

> No need for the “unsafe” keyword unless something is known to be less safe than normal C++. > For a Rustacean, this is controversial - all C++ is unsafe! Isn't this just a fundamental misunderstanding of what unsafe really means, and as such a nonsense goal that doesn't gain anything? Unsafe is a Rust language definition, and defines whether the rust compiler can vouch for the safety of some code. As such, calling…

The usual understanding is that an unsafe function is any function that can, if passed the wrong arguments, cause Undefined Behavior. A lot of Rust’s std and library ecosystem provides safe wrappers around underlying unsafe C APIs, by cleverly using borrow semantics and performing additional runtime checks. The bar for safety is lower than you might expect, for example, crashing with a “panic” in case of an error is…

> For example, field destruction order in Rust is weird and you often don’t control it as carefully as you would in C++.

This is well-defined, as being dropped in the order that they are declared.

Re: Rust and C++ Interoperability in Chrome

#90

Post by roca »

rvz wrote: post #88
roca wrote: post #82

Earlier quoted context omitted.

If you care about security, it is much easier to write non-exploitable code in Rust than in C++, and you can hire accordingly. Actually, the people who are really experienced at writing secure code in C++ understand that they can't do it reliably, and an increasing number of them (like me) would much rather write Rust code instead for that reason. So for secure code the hiring advantage is tilting away from C++ towar…

Yet once the Chromium team goes down that Rust to C++ FFI route, they will encounter the same old bugs outlined in this paper. [0] They might as well fork Servo and create their own engine from that, but even that is still a prototype worked on for years with zero C++ at least. It's too early to see how the Chromium team will begin to work on this given it's only a plan, but maybe the unsafety and security issues are…

None of this logic follows. Paper [0] categorizes bugs in unsafe Rust code. "There will be some bugs in FFI code" does not imply "no benefit to using Rust if there is C++ FFI". Many projects, including Firefox, have found Rust is really helpful even if you have C++ FFI.
Post reply on HN