Chromium, the project underpinning Microsoft Edge, Opera, Vivaldi, and dozens more browsers, will support the use of third-party Rust libraries from C++. The team is putting in place the tools to enable Rust code in the Chrome binary within the next year, according to Dana Jansens of the Chrome security team. “We are now actively pursuing adding a production Rust toolchain to our build system,” writes Jansens. Allowing Rust for third-party libraries in Chromium is a significant move towards a modern, memory safe language, but it’s far more limited than the Android Open Source Project (AOSP), which brought Rust in as a new platform language in April 2021 on top of C and C++. Also: Programming languages: Why this old favorite is on the rise again AOSP allows Rust for the development of native OS components and now accounts for 21% of new code in AOSP. The shift has coincided with a fall in memory safety vulnerabilities from 76% to 35% of Android’s total vulnerabilities. AOSP, AWS, the Linux kernel project, Meta, Microsoft and many more are adopting Rust in systems programming for its memory safety guarantees. Broadly, Rust can help reduce memory-related vulnerabilities – that make up the vast majority of software security issues – introduced by code written in memory-unsafe C and C++, which allow programmers to easily break memory safety rules. Apple in October detailed how it was addressing memory safety in XNU, the kernel used for the iPhone, iPad, and Mac. The Chrome security team last year said it had considered Rust as a platform language but opted to maintain C++ as its primary language for the foreseeable future while it attempts to bring memory safety to C++ through projects like its MicraclePtr C++ smart pointers. Jansens, however, suggests the Chrome security team hasn’t completely canned the idea of bringing Rust into Chromium and details how it continues to explore how Rust could fit in over time. For now, the Chromium project has put several constraints on Rust for these libraries. For example, it will allow Rust for Chromium third-party libraries if there is a “business need”, such as meaningfully reducing the risk of memory bugs, crashes, and other issues “when compared to the existing third-party library and related C++ code required to use the library”. “We’re starting slow and setting clear expectations on what libraries we will consider once we’re ready,” notes Jansens. She says her team has been exploring “the implications of incrementally moving to writing Rust instead of C++, even in the middle of our software stack” and understanding “what the limits of safe, simple, and reliable interoperability might be.” Also: Low-code is not a cure for overworked IT departments just yet Besides limiting Rust support to third-party libraries, the team has opted to support only one-way interoperability – from C++ to Rust – to control the shape of the dependency tree. “Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++,” notes Jansens. Jansens explains it’s too risky to allow full cross-language C/C++ and Rust interoperability. The team looked at the implications of building Rust components against Chrome’s “really wide C++ APIs”. “At a high level what we found was that because C++ and Rust play by different rules, things can go sideways very easily,” she notes. There’s also currently a lack of interoperability (interop) tools providing support from the compiler and type system of each language. She points to the problem of concepts in one language not existing in another. Google is working on a C++/Rust bidirectional interoperability tool called Crubit. However, Google describes it as an “extremely experimental” tool at this stage and advises against using it. “Without interop tools providing support via the compiler and the type system, developers would need to understand all of the assumptions being made by Rust compiler, in order to not violate them from C++,” she notes. “In this framing, C++ is much like unsafe Rust. And while unsafe Rust is very costly to a project, its cost is managed by keeping it encapsulated and to the minimum possible. In the same way, the full complexity of C++ would need to be encapsulated from safe Rust. Narrow APIs designed for interop can provide similar encapsulation, and we hope that interop tools can provide encapsulation in other ways that allow wider APIs between the languages.”
