Bringing Rust to the Pixel Baseband

* Google is focusing on hardening the cellular baseband modem against exploitation.
* The Pixel 9 shipped with mitigations for memory-safety vulnerabilities.
* The project involves integrating a memory-safe Rust DNS parser into modem firmware.
* The goal of the parser is to mitigate class of vulnerabilities in the modem.
* The DNS protocol requires parsing untrusted data, which can lead to vulnerabilities in memory-unsafe implementations.
* `hickory-proto` was selected as the open-source Rust DNS library due to maintenance and test coverage.
* Support for `nostd` was added to `hickory-proto` and its dependencies through pull requests.
* A code size study showed a sum of 371KB for prototype implementation including core components, Hickory-proto, and Shim.
* The integration strategy used Cargo and Rust tools, compiling crates to `rlib` before linking with the modem build system (Pigweed).
* Dynamic memory allocation support was implemented by creating a `GlobalAlloc` implementation interfacing with C allocator APIs.
* A panic handler was implemented to interface Rust panics with the existing C crash backend.
* The final integration required fixing symbol conflicts during linking by stripping symbols from the `compilerbuiltin` crate before linking.
* A Rust function for DNS response processing was exposed via FFI, using `bindgen` for callback generation.

The narrative positions the adoption of memory-safe languages as an essential security evolution for critical embedded systems like cellular modems, shifting the focus from post-hoc patching to proactive design. The pattern observable here is the friction created when introducing new, high-assurance paradigms (Rust/memory safety) into legacy, complex, and highly constrained environments (firmware). While the technical steps—choosing libraries, managing FFI, handling build systems—are pragmatic and demonstrate a strong commitment to engineering rigor, the necessity of dealing with weak symbol definitions during linking suggests that existing development toolchains are not inherently designed for this seamless integration. The perceived value is simultaneously demonstrated by patching an attack surface and laying a foundational pattern for future development, which resists being purely framed as a technical chore; it is presented as a necessary security trajectory. The cost analysis regarding code size introduces a predictable bottleneck, suggesting that the transition to memory safety in embedded systems must account not just functional correctness but also strict resource constraints from the outset.
BRIDGE QUESTIONS: How can build systems evolve to natively manage and reconcile complex dependency graphs between high-level systems like Rust and low-level C/C++ firmware without introducing manual symbol stripping? What frameworks exist to abstract away the memory/safety dichotomy during legacy code integration, allowing for incremental migration rather than large-scale rewrites? What are the long-term systemic costs associated with deferring necessary foundational shifts in embedded development tooling to achieve immediate security gains?