Returning the same mutable pointer from a function twice, where the first may still be held.If these C++ pointers were also used as Rust references in a complex or long-lived way, it would require our C++ authors to understand the aliasing rules of Rust and prevent the possibility of violating them, such as by: This is especially true in our browser process, which contains a giant interconnected system of (mutable) pointers. We have cyclical mutable data structures. We hold redundant mutable pointers throughout the system, and pointers that provide multiple paths to reach mutable pointers. The latter is incompatible with how the majority of Chromium’s C++ is written. At a high level what we found was that because C++ and Rust play by different rules, things can go sideways very easily.įor example, Rust guarantees temporal memory safety with static analysis that relies on two inputs: lifetimes ( inferred or explicitly written) and exclusive mutability. We examined what it would mean for us to build Rust components against these types of APIs. Chrome is built on foundational but really wide C++ APIs, such as the //content/public layer. libraries for QUIC or bluetooth, Linux drivers) or through clearly isolated components (e.g. We have observed that most successful C/C++ and Rust interop stories to date have been built around interop through narrow APIs (e.g. The Interop Between Rust and C++ in Chromium We will be reviewing libraries that we bring in for C++ use to ensure they fit this expectation. Or, put another way, they typically have a narrow interface, without complex pointer graphs and shared ownership. This means they have APIs that are simpler and focused on their single task. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium. We will only support third-party libraries for now.In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++. Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. By limiting interop to a single direction, we control the shape of the dependency tree. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. We will support interop in only a single direction, from C++ to Rust, for now.What the limits of safe, simple, and reliable interop might be.īased on our research, we landed on two outcomes for Chromium. Understanding the implications of incrementally moving to writing Rust instead of C++, even in the middle of our software stack. The Chrome Security team has been investing time into researching how we should approach using Rust alongside our C++ code. How Chromium Will Support the Use of Rust We can expect that the shape of these limitations will change in time through new or improved tools, but the decisions and descriptions here are based on the current state of technology. We know that C++ and Rust can play together nicely, through tools like cxx, autocxx bindgen, cbindgen, diplomat, and (experimental) crubit. Rust has been an incredible proof that we should be able to expect a language to provide safety while also being performant. Thank you Mozilla for your huge contribution to the systems software industry. 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. And we believe that we can use third-party Rust libraries to work toward this goal. Our goal in bringing Rust into Chromium is to provide a simpler (no IPC) and safer (less complex C++ overall, no memory safety bugs in a sandbox either) way to satisfy the rule of two, in order to speed up development (less code to write, less design docs, less security review) and improve the security (increasing the number of lines of code without memory safety bugs, decreasing the bug density of code) of Chrome. In this blog post, we will discuss how we arrived at the decision to support third-party Rust libraries at this time, and not broader usage of Rust in Chromium. We’re starting slow and setting clear expectations on what libraries we will consider once we’re ready. This will enable us to include Rust code in the Chrome binary within the next year. To do so, we are now actively pursuing adding a production Rust toolchain to our build system. We are pleased to announce that moving forward, the Chromium project is going to support the use of third-party Rust libraries from C++ in Chromium. Posted by Dana Jansens (she/her), Chrome Security Team
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |