BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Chromium to Allow the Use of Third-Party Rust Libraries to Improve Safety and Security

Chromium to Allow the Use of Third-Party Rust Libraries to Improve Safety and Security

This item in japanese

The Chromium Project is going to add a Rust toolchain to its build system to enable the integration of third-party libraries written in Rust with the aim of improving security, safety, and speed up development.

Rust was developed by Mozilla specifically for use in writing a browser, so it's very fitting that Chromium would finally begin to rely on this technology too. Thank you Mozilla for your huge contribution to the systems software industry. Rust has been an incredible proof that we should be able to expect a language to provide safety while also being performant.

The promise that Rust brings to the Chromium Project, explains Dana Jansens, member of the Chromium Security Team, is providing a simpler and safer way to satisfy Chromium's "rule of two", which governs how to write code to parse, evaluate, or handle untrustworthy inputs from the Internet in a safe way.

The rule states that only two of the following conditions may hold at the same time: untrusted inputs, unsafe language use, and high execution privilege. For example, a C/C++ program, being inherently unsafe, can only process untrustworthy inputs in a process with very low privilege, i.e. in a sandbox. If C/C++ code is only used instead to process trustworthy inputs, then the sandbox is not required.

There are a number of benefits that the team aims to gain thanks to the introduction of Rust, including the ability to use a simpler mechanism than IPC, less complexity at the language level, less code to write and review, and reducing the bug density of the code. Those should contribute to Chromium overall safety, security, and development velocity.

It is important to observe that the Chromium Project is only considering the integration of Rust libraries, and not the broader adoption of Rust as a development language.

We will only support third-party libraries for now. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium. This means they have APIs that are simpler and focused on their single task. Or, put another way, they typically have a narrow interface, without complex pointer graphs and shared ownership.

Besides, there are only a fixed number of cases in which a Rust library will be considered for integration. In particular, the Rust implementation should be the best in terms of speed, memory, and bugs; it should allow moving the task to a higher privileged process to reduce the cost of IPC or C++ memory-safety mitigation; or, it should bring an advantage in terms of bug risks in comparison to alternatives.

In symmetry with their stepwise approach to the coexistence of Rust and C++ code, the Chromium team is limiting interop to only be allowed from C++ to Rust. Jansens provides a reasoned overview of the complexities inherent to allowing full interoperability including the possibility that safe Rust code land in intrinsically unsafe C++ code if a call from Rust to C++ were allowed, or the need for C++ developers to understand Rust rules to avoid violating them.

Full interop is not ruled out for the future, anyway, but it will require a significant investment in and evolution of interop tooling to ensure everything works smoothly. Meanwhile, the Chromium Team decision aims to gain access to the wealth of crates provided by the Rust ecosystem without incurring big penalties.

About the Author

Rate this Article

Adoption
Style

BT