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

101–110 of 115 posts

Re: Experimenting with Rust in Chromium

#101

Post by staticassertion »

yjftsjthsd-h wrote: post #79
selfmodruntime wrote: post #46

Earlier quoted context omitted.

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…

TBH it's only easy if you're ignorant. It's quite obvious to anyone who's informed or educated at all that using Rust would address major security issues. It sucks that people require so much convincing.

Re: Experimenting with Rust in Chromium

#102

Post by bluejekyll »

tialaramex wrote: post #59
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.

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

> work by Mozilla and Apple

Don’t forget the origin of WebKit, KHTML from the KDE folks.

Re: Experimenting with Rust in Chromium

#103

Post by staticassertion »

comment500 wrote: post #51
selfmodruntime wrote: post #46

Earlier quoted context omitted.

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.

Yes, that's a really good point. The vulnerabilities are across a number of components (skia, for example, is another big one) but memory safety in VMs is particularly tricky. Still, my personal, somewhat unfounded belief is that Rust has a lot of potential there.

Re: Experimenting with Rust in Chromium

#104

Post by jcelerier »

tialaramex wrote: post #93
jcelerier wrote: post #69

Earlier quoted context omitted.

> 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

The C++ API lets you take references into the string. These, understandably, are lightweight, no C++ programmer would expect a reference into the sixth character of a string s[5] to be expensive to make or carry about, but they're mutable and as a result of being lightweight they are not reference counted... So I've got the string "IR Baboon big star of cartoon" and I take references into it, which are cheap and then…

> The C++ API lets you take references into the string

> and then I scrawl "I AM Weasel" on top of my string using my reference and now your string was changed because it was COW.

I mean, that's the point of references... no ? If I wanted a different object I'd make a copy.

Like, even with just one string, without any CoW, your post makes it sound like you'd be surprised than if you had:

    void set_some_config(const char*);
    char* get_some_config();

    std::string s = "foo";
    set_some_config(&s[1]);
    s = "bar";
    get_some_config();
you'd get "ar" in get_some_config().

Re: Experimenting with Rust in Chromium

#105

Post by TheCoelacanth »

sseagull wrote: post #66
seritools wrote: post #63

Earlier quoted context omitted.

`.clone()` is visible right in your code, though, unlike the implicit conversion/constructor magic.

But you could write a C++ class with a manual .copy() method and a deleted copy constructor (and other conversion constructors not implemented). Doing that seems a bit easier than integrating a whole new language into your project (although I know Rust would have other benefits).

You could do that if you are the author of std::string. Unfortunately, very few of us are.

Re: Experimenting with Rust in Chromium

#106

Post by tialaramex »

jcelerier wrote: post #104
tialaramex wrote: post #93

Earlier quoted context omitted.

The C++ API lets you take references into the string. These, understandably, are lightweight, no C++ programmer would expect a reference into the sixth character of a string s[5] to be expensive to make or carry about, but they're mutable and as a result of being lightweight they are not reference counted... So I've got the string "IR Baboon big star of cartoon" and I take references into it, which are cheap and then…

> The C++ API lets you take references into the string > and then I scrawl "I AM Weasel" on top of my string using my reference and now your string was changed because it was COW. I mean, that's the point of references... no ? If I wanted a different object I'd make a copy. Like, even with just one string, without any CoW, your post makes it sound like you'd be surprised than if you had: void set_some_config(const ch…

> If I wanted a different object I'd make a copy.

In the explanation I posted, you do make a copy to get a different object "you use your C++ 98 copy constructor to get another string".

The problem happens because both strings share the same bytes to represent the text "IR Baboon big star of cartoon" as part of the COW optimisation. But my reference can scribble on this shared text.

I don't see how your get_some_config is similar at all. Notice that with C++ 11 strings, the copy constructor gives you a deep copy of that "IR Baboon" text and so my references can't smash your string.

Re: Experimenting with Rust in Chromium

#107

Post by brabel »

throwaway894345 wrote: post #86
brabel wrote: post #58

Earlier quoted context omitted.

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.

Security isn't a binary, and the vulnerabilities that are possible in a memory safe language are a subset of those possible in a memory unsafe language. We want to minimize the number of possible vulnerabilities. Yes, the above is a bit oversimplified: most memory-safe languages have an "unsafe" escape hatch, so technically these vulnerabilities are possible; however, these escape hatches are rarely used, explicitly…

I was not the one claiming security is binary. The opposite of that (I happen to work in security)... people just casually claiming that 100% of the vulnerabilities in Chromium are due to memory unsafety are implicitly claiming that none of them were logic bugs and what follows is that had the same code been written in Java, Rust, even Python for that matter, none of those vulnerabilities would've been possible - which means there would be no vulnerabilities at all!? I would expect people commenting here to have basic understanding of propositional logic.

Re: Experimenting with Rust in Chromium

#108

Post by tialaramex »

vlovich123 wrote: post #65
mseepgood wrote: post #18

Earlier quoted context omitted.

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

Everyone’s trying to justify the response when the honest truth is that no, Rust doesn’t solve the problem of abstraction layer impedance mismatches causing ownership to be dropped only to be reacquired at the next level. On a sufficiently large/complicated code base, the problem will arise. As others have mentioned, various kinds of string types are baked into the language which makes it ergonomic to do “the right t…

> Rust doesn’t solve the problem of abstraction layer impedance mismatches causing ownership to be dropped only to be reacquired at the next level

The expression of what C++ does here in Rust is awkward and, I think, nobody has proposed it because you'd never write that. Basically C++ char* is a raw pointer. Rust does have those, but you'd never use them in this context.

What you would use is either the borrowed slice reference &str or the owning String type, but in both cases we have an owned object and there's our crucial difference. If you've got the owned String, and I needed an owned String, I should ask for your owned String, and we're done.

In C++ "dropping" ownership as you describe is no big deal, the C++ design doesn't care, but in Rust if you actually drop(foo) it's gone. The references to it can't out-live that, if it's gone then they're gone. If you write code that gives away references and then tries to drop the thing they're references to, Rust will object that this is nonsense, because it is nonsense, you need to ensure those references are gone before dropping the thing they refer to.

As a result I feel you're greatly under-estimating the ergonomic difference.

Re: Experimenting with Rust in Chromium

#109

Post by vlovich123 »

tialaramex wrote: post #108
vlovich123 wrote: post #65

Earlier quoted context omitted.

Everyone’s trying to justify the response when the honest truth is that no, Rust doesn’t solve the problem of abstraction layer impedance mismatches causing ownership to be dropped only to be reacquired at the next level. On a sufficiently large/complicated code base, the problem will arise. As others have mentioned, various kinds of string types are baked into the language which makes it ergonomic to do “the right t…

> Rust doesn’t solve the problem of abstraction layer impedance mismatches causing ownership to be dropped only to be reacquired at the next level The expression of what C++ does here in Rust is awkward and, I think, nobody has proposed it because you'd never write that. Basically C++ char* is a raw pointer. Rust does have those, but you'd never use them in this context. What you would use is either the borrowed slic…

> In C++ "dropping" ownership as you describe is no big deal, the C++ design doesn't care, but in Rust if you actually drop(foo) it's gone

I think you’ve built a straw man of my argument and then argued with that.

Clearly I meant that it seems possible that a sufficient complicated call stack could still be set up to jump between needing the owned String type and the borrowed &str type. That’s what I meant by dropping ownership as that’s what’s happening in the c++ code when you go between char*/string (the API is dropping its need for ownership). The argument of “ If you've got the owned String, and I needed an owned String, I should ask for your owned String, and we're done” is weak because that same argument would apply to C++ code and yet the code still ended up that way when you pasted together components in a very large code base. Now maybe it’s a bit simpler because you have string, string&, const string&, and const char* and doing that antipattern that happened in C++ just wouldn’t be ergonomic in Rust. Maybe. But that feels like a very thin argument and not “this is impossible in Rust”.

Re: Experimenting with Rust in Chromium

#110

Post by tialaramex »

vlovich123 wrote: post #109
tialaramex wrote: post #108

Earlier quoted context omitted.

> Rust doesn’t solve the problem of abstraction layer impedance mismatches causing ownership to be dropped only to be reacquired at the next level The expression of what C++ does here in Rust is awkward and, I think, nobody has proposed it because you'd never write that. Basically C++ char* is a raw pointer. Rust does have those, but you'd never use them in this context. What you would use is either the borrowed slic…

> In C++ "dropping" ownership as you describe is no big deal, the C++ design doesn't care, but in Rust if you actually drop(foo) it's gone I think you’ve built a straw man of my argument and then argued with that. Clearly I meant that it seems possible that a sufficient complicated call stack could still be set up to jump between needing the owned String type and the borrowed &str type. That’s what I meant by droppin…

I am definitely not arguing that it's impossible but my experiences with Rust lead me to think you've significantly underestimated how important those ergonomics are.

The "I should ask for your owned String" argument does not apply equally well in C++ because of a crucial design infelicity in C++. Your caller may well not have an owned std::string.

In C++ raw char pointers are totally a thing. Because std::string is a late addition (if you learned C++ in the early 1990s a "string" class was maybe an interesting exercise, not a library type) the string literals aren't a built-in string type, and much of the API isn't shaped for such a type either.

Now, the effect is those are (sometimes) owning pointers, it is possible I own some C++ string in this sense, and all I have is a pointer into it. If I give you that pointer, it's not because I didn't give you the owned string, that pointer is my owned string. You want a std::string and there's no reason I would have one at all.

You can mutate these strings, but of course you can't extend them because you've got no way to know how to communicate with the allocator, maybe they live on the stack, or in a private heap. At the time this seemed like a good idea, today we don't think so.

Post reply on HN