An update on Memory Safety in Chrome [LWN.net]

The Google security blog provides an overview of what is being done to address memory-safety problems in the Chrome browser.

In parallel, we’ll be exploring whether we can use a memory safe language for parts of Chrome in the future. The leading contender is Rust, invented by our friends at Mozilla. This is (largely) compile-time safe; that is, the Rust compiler spots mistakes with pointers before the code even gets to your device, and thus there’s no performance penalty. Yet there are open questions about whether we can make C++ and Rust work well enough together. Even if we started writing new large components in Rust tomorrow, we’d be unlikely to eliminate a significant proportion of security vulnerabilities for many years.

to post comments

An update on Memory Safety in Chrome

Posted Sep 22, 2021 19:57 UTC (Wed) by Karellen (subscriber, #67644) [Link] (18 responses)

It seems a bit odd that this Google security blog post makes no mention of the other 2010-era memory-safe, statically-typed, multi-paradigm, compiled, C-replacement programming language - Google's go(lang).

An update on Memory Safety in Chrome

Posted Sep 22, 2021 21:08 UTC (Wed) by philipstorry (subscriber, #45926) [Link] (9 responses)

I'm no expert, but I'd guess that this is due to Go's use of garbage collection.

From the article: You’ll see major investments in C++ safety solutions - such as MiraclePtr and ABSL/STL hardened modes. In each case, we hope to eliminate a sizable fraction of our exploitable security bugs, but we also expect some performance penalty. For example, MiraclePtr prevents use-after-free bugs by quarantining memory that may still be referenced. On many mobile devices, memory is very precious and it’s hard to spare some for a quarantine. Nevertheless, MiraclePtr stands a chance of eliminating over 50% of the use-after-free bugs in the browser process - an enormous win for Chrome security, right now.

If you're worried about memory usage with certain patterns or enhancements in C++, then a garbage collected language is probably out of the question.

An update on Memory Safety in Chrome

Posted Sep 23, 2021 1:47 UTC (Thu) by developer122 (guest, #152928) [Link]

Just what we need: chrome eating EVEN MORE memory. ;P

An update on Memory Safety in Chrome

Posted Sep 23, 2021 6:59 UTC (Thu) by eru (subscriber, #2753) [Link] (7 responses)

Modern C++ usage with extensive use of containers, shared_ptr etc. seems to essentially practice reference counting garbage collection, whose implementation is just split over the various classes. I wonder if a language with builtin garbage collection implemented using modern algorithms might actually be as efficient, or more so.

An update on Memory Safety in Chrome

Posted Sep 23, 2021 8:35 UTC (Thu) by smcv (subscriber, #53363) [Link] (6 responses)

I believe garbage collection is generally used to refer to memory management approaches where instead of proactively tracking memory ownership (like reference counting or Qt's "owner" model), you just discard objects you have finished with, and let the garbage collector clean them up.

The big advantage of reference counting over garbage collection is that when the last user of an object has finished using it, the object is freed immediately, rather than at some undefined time in the future when the garbage collector runs; this keeps memory consumption as low as possible at all times.

The big advantage of garbage collection over reference counting is that it can clean up objects with circular references, whereas in a reference-counted model you have to be careful to avoid circular references (which would never be freed), for instance by using ordinary references in one direction and "weak references" in the other.

Garbage-collected runtimes like Java and the use of Javascript in gnome-shell often run into memory consumption problems where an object is directly or indirectly responsible for a lot of resource use, but isn't cleaned up promptly, resulting in the resources appearing to be leaked. They are not *actually* leaked, and will be freed *eventually*, but eventually is not necessarily soon enough to be practically useful.

An update on Memory Safety in Chrome

Posted Sep 23, 2021 18:12 UTC (Thu) by eru (subscriber, #2753) [Link] (5 responses)

I recall reading a survey article on various garbage collection methods, and it started with reference counting. So at least some people consider it a form of garbage collection. Certainly garbage collectors do not solve all memory leak problems. The programmer should take some care to avoid needlessly keeping references to probably unneeded objects. But setting some variable null just in case in Java or JavaScript is safer than applying delete to it in C++, because nothing bad happens if it was still being referenced elsewhere.

The C++ way of doing things really breaks down when you introduce concurrency and lambda:s.(Sadly I have had to deal with code like that recently). Errors in setting "captures" gives rise to subtle bugs. I hope Rust brings sanity here, at least there is no way it can be worse.

An update on Memory Safety in Chrome

Posted Sep 24, 2021 7:56 UTC (Fri) by marcH (subscriber, #57642) [Link] (4 responses)

> I recall reading a survey article on various garbage collection methods, and it started with reference counting.

The "garbage" analogy is fairly obvious: it means something that nothing uses (refers to) any more but that is still there consuming memory. So the difference between GC vs no-GC is all about timing: is the memory freed as soon as it's not in use anymore or later in a dedicated GC task.

I thought reference counting implied that there is never any garbage left because it's freed as soon as the last reference is gone but maybe I'm misunderstanding reference counting.

> I hope Rust brings sanity here

https://www.google.com/search?q=rust+fearless+concurrency

An update on Memory Safety in Chrome

Posted Sep 24, 2021 8:56 UTC (Fri) by mgedmin (guest, #34497) [Link] (3 responses)

> I thought reference counting implied that there is never any garbage left because it's freed as soon as the last reference is gone but maybe I'm misunderstanding reference counting.

Imagine a self-referential data structure (e.g. a DOM tree where each node has a parent pointer and a list of pointers to child nodes). Now imagine that the last actual user drops the reference to the root node and there are no outside references to other nodes either. But the internal references between the parent and child nodes keep reference counts greater than zero, which means the entire structure cannot be freed!

An update on Memory Safety in Chrome

Posted Sep 27, 2021 1:11 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)

According to the interwebs, combining circular references with a "naive" reference counting scheme is a bug in your program. Don't do it. If you really need to do all this, then you must use "weak" reference already mentioned above or some other advanced feature.

I did some more reading and I still think that there is no overlap between garbage collection and "reference counting" in the most common use of these two terms.

Maybe some confusion comes from the fact that a garbage collector also counts references _internally_? However these counts are not accessible to the program, not even with any super private or reflexion API. This draws a very clear line between the two cases.

Speaking of vague terminologies and confusions, what is frequently called a "memory leak" in Java is indeed very different from a memory leak in C/C++. In the latter the programmer lost the pointer whereas in Java the programmer... forgot to lose it! Yet the net effect is pretty much the same, so which side holds the One True Definition of "Memory Leak"? Need some language lawyers...

An update on Memory Safety in Chrome

Posted Sep 27, 2021 7:51 UTC (Mon) by mbunkus (subscriber, #87248) [Link]

Another differentiating property seems to be that with reference counting schemes it's entirely deterministic when objects are destructed/resources are freed (barring multi-threading etc.), whereas a garbage collector runs in intervals and bulk-frees objects during such a run. There have been a lot of cases with garbage-collected languages where this type of bulk removal and the associated "stopping of the world" or at least load spikes have proved to be problematic, and programs have very limited ways to deal with it. d whereas you have full control of when this happens in reference counted design.

An update on Memory Safety in Chrome

Posted Sep 27, 2021 20:25 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

Any system where the programmer does not need to manually free objects—where one can just allocate objects and let the system clean them up when they are no longer needed, whether immediately or at some later time—qualifies as having "automatic garbage collection". This includes systems based on reference counting (such as Perl and Swift, or C++, Rust, et al. via smart pointers) as well as systems which don't count references at all.

Whether the programmer can read the reference counts or other garbage collection state is an implementation detail; some systems are fairly open about their internal state while others keep this information hidden. In Perl, for example, one can use Devel::Refcount::refcount to get an object's current reference count; the Core Foundation function CFGetRetainCount() serves the same purpose in Swift.

There is nothing in the definition of garbage collection which precludes a guarantee of *precise* collection at the exact point where the object is no longer accessible; reference counting is just one of the few GC systems which can implement precise collection efficiently (in the absence of cycles). And of course most GC languages include some form of FFI which can allocate memory outside the reach of the default garbage collector, so the fact that one is not obligated to use any particular implementation of smart pointers in C++ or Rust is not an obstacle; the GC is merely opt-in rather than opt-out.

Technically stack allocation qualifies as a form of garbage collection, since the memory for stack-allocated objects is freed automatically when they go out of scope, so in that sense even C could be considered a garbage-collected language—albeit only for certain kinds of objects and with much less protection than most GC language provide against user error.

An update on Memory Safety in Chrome

Posted Sep 22, 2021 21:31 UTC (Wed) by roc (subscriber, #30627) [Link] (1 responses)

Go increases the FFI problem considerably by adding GC and its own threading model.

Go isn't actually memory safe in the face of data races.

Less relevant to this blog post, but important for the overall picture, Rust has a higher performance ceiling and considerable security and reliability benefits over Go (e.g. static prevention of data races, no null references, and a much more expressive type system).

Go has advantages over Rust --- developer velocity and ease of onboarding in particular --- but it's not difficult to see why for infrastructure like Chrome you would prefer Rust.

An update on Memory Safety in Chrome

Posted Sep 22, 2021 21:52 UTC (Wed) by daniel (guest, #3181) [Link]

Came here to post that but you said it better and more succinctly than I would have.

An update on Memory Safety in Chrome

Posted Sep 22, 2021 22:56 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> 2010-era memory-safe, statically-typed, multi-paradigm, compiled, C-replacement programming language

It is not a C replacement. In practice, it has been more of a Python replacement (or maybe PHP, Ruby or Java replacement). To replace C, it was originally C++ and more recently Rust. This is why Google is pushing for Rust in Chrome, Android (Linux kernel) etc.

An update on Memory Safety in Chrome

Posted Sep 23, 2021 2:17 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

Small correction: Google is not pushing Rust anywhere. Not yet.

What it does, though, are pilot projects. In Android, Chrome, main Google repo…

Everyone likes Rust, but few like C++ ⟷ Rust interoperability story. And without solid C++ ⟷ Rust interoperability you couldn't introduce Rust into billion-LOC codebase.

An update on Memory Safety in Chrome

Posted Sep 23, 2021 11:42 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

> Small correction: Google is not pushing Rust anywhere. Not yet.

Quite note: I said pushing for, not pushing. Different connotations.

An update on Memory Safety in Chrome

Posted Sep 23, 2021 8:11 UTC (Thu) by fw (subscriber, #26023) [Link] (2 responses)

Technically, Go is not memory-safe. If you have data races, you can end up with buffer overflows or type-confusion problems. It's different from Java in this regard, where data races cannot be used to subvert the type system.

Data races

Posted Sep 23, 2021 16:32 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (1 responses)

roc mentions this above, but this seems like a better place to address what the difference works out to be:

In (safe) Rust you can't write data races. They won't compile.

In Java, you can write data races. Java promises that your program still has defined behaviour, but the potential behaviour may seem very strange. The objects touched in the race are definitely still valid, but it doesn't promise what their value is exactly. Other objects are unharmed.

In Go, you can write data races. Go promises that so long as your race only touches elementary objects like integers, only those objects are smashed, and so long as you don't think about them you're fine. If you race anything with structure (e.g. a string or container), you get Undefined Behaviour. If you think about elementary objects you've smashed they might (depending on the elementary type) now be nonsense and cause Undefined Behaviour.

In C++ of course you can write data races. The standard says only that if your program has potential data races it has Undefined Behaviour. Good luck.

So this is a continuum. When Java chose where to be on that continuum the belief was that Data Race Freedom is too expensive (arguably disproved by Rust) and unnecessary because programmers could learn to debug programs with Data Races so long as the behaviour remained defined. This has not proved true.

Data races

Posted Sep 24, 2021 8:03 UTC (Fri) by marcH (subscriber, #57642) [Link]

> When Java chose where to be on that continuum the belief was that Data Race Freedom is too expensive (arguably disproved by Rust) and unnecessary because programmers could learn to debug programs with Data Races so long as the behaviour remained defined. This has not proved true.

Not true but you can avoid races entirely by sticking to higher level libraries that solve that problem for you. At least in Java that's relatively easy.

An update on Memory Safety in Chrome

Posted Sep 23, 2021 8:12 UTC (Thu) by oldtomas (guest, #72579) [Link] (1 responses)

Oh, yes, please, Google, do it!

Please, invent yet another new language, one that will, once again, solve all of our problems! Make yet another web site for it which, instead of docs, looks like a cheery, colourful travel agency leaflet!

Let's call it "Redemption Reloaded"!

Sorry for the snark, folks ;-P

An update on Memory Safety in Chrome

Posted Sep 23, 2021 8:39 UTC (Thu) by beagnach (guest, #32987) [Link]

Try reading to the end before snark

a) They're talking about "a new language *in Chrome*", i.e. introducing an existing language (Rust), not creating a new one from scratch.

b) Go has been a very useful and successful addition to the ecosystem.

Granted, Go's website is cheery.

Nonetheless, maybe save sark for occasions where you've read the article to the end and have a well grounded point to make.

An update on Memory Safety in Chrome

Posted Sep 28, 2021 1:07 UTC (Tue) by KaiRo (subscriber, #1987) [Link]

C++ and Rust can work together as current Firefox (and/or its Gecko "Quantum" engine) has proven, to some degree at least. And yes, it takes years to rework a web virtual engine (neé browser) to use Rust components, as Firefox has been and still is showing.
Your "friends at Mozilla" have a few things to teach you here - but if it works out well, hey, everyone ob the web profits!