Press "Enter" to skip to content

Google putting its trust in Rust to weed out memory bugs in Android development

Google has signalled support for the Rust programming language in low-level system code to limit the prevalence of memory-based security vulnerabilities.

The Android project has largely been built in two languages. Java (and more recently, JVM-compatible languages like Kotlin) have been favoured for higher-level parts of the operating system, such as the UI. OS fundamentals, like the kernel and drivers, have typically been written in C, and, to a lesser extent, C++.

C and even C++ are considered well suited for system-level programming as they offer a degree of closeness to the underlying hardware that’s hard to achieve with higher-level languages. There are no intermediate layers of abstraction, like the Java virtual machine. C is also highly portable, and developers are left to their own devices when it comes to things like memory handling.

But this flexibility has repeatedly proven to be a double-edged sword. With no garbage collection to rely on, simple memory management errors frequently result in serious security issues, such as buffer overflows and overreads. According to Google, memory-safety bugs represent 70 per cent of all high-severity security vulnerabilities found in the Android Open Source Project.

Introduced in 2010 by Mozilla, the Rust programming language provides a happy medium between the low-level power of C and the memory safety found in higher-level languages like Java.

But its approach is novel. Rust doesn’t place the same emphasis on manual memory management like C. Nor does it come with a Java-style garbage collector (although the existence of a Rust garbage collector is a somewhat contentious topic). Rather, it takes a third tack, with memory usage linked inextricably to scope.

If Google and Apple won’t help us, we’ll sort it out the Linux way: 21 companies form Mobile Native Foundation

READ MORE

A core concept of Rust is ownership. Put simply, every value has an owner. When that owner goes out of scope, the value is dropped. This limits the risk of memory-based security bugs, while also limiting the amount of code needed to be written to ensure safety.

Additionally, Rust requires all variables be initialised before use, preventing an issue that Google claims is the root cause of between 3 and 5 per cent of all Android security vulnerabilities. Rust also comes with native protections against buffer overflows, another memory security woe.

Google has said it doesn’t intend to start rewriting the entire OS in Rust, which would be a mammoth undertaking given the millions of lines of code within Android. Rather, it intends to use Rust going forward. This, it said, is due to the disproportionate amount of memory-safety errors in newly written code. Vintage code is comparatively more robust, with errors already weeded out.

Android’s adoption of Rust won’t happen overnight. Describing the task as “a large undertaking,” Google highlighted the vast amounts of underlying work needed to be done. “There are toolchains and dependencies that need to be maintained, test infrastructure and tooling that must be updated, and developers that need to be trained,” it said.

Scaling the language to widespread use will be a “multi-year project,” although the company has some early-adopter projects in the pipeline that rely on Rust.

Android’s embrace of Rust is indicative of the language’s growing popularity. In July last year, Linus Torvalds suggested Rust may find a place in the Linux project, particularly with respect to device drivers. This preceded the porting of the GNU Coreutils suite (which is a suite of basic file, shell and text manipulation utilities) to Rust in 2020 by Debian developer and Mozilla director Sylvestre Ledru. ®

source: The Register