Bringing Rust to the Pixel Baseband

Summary

Google is hardening the Pixel 10 cellular baseband modem by integrating a memory-safe Rust DNS parser, replacing the original C/C++ implementation. This effort mitigates an entire class of memory-safety vulnerabilities in the modem firmware, particularly addressing risks like CVE-2024-27227. The project uses the hickory-proto Rust crate with no_std support, demonstrating a practical approach to adopting memory-safe languages in low-level firmware environments.

Full text

<span class="byline-author">Posted by Jiacheng Lu, Software Engineer, Google Pixel Team</span> <p>Google is continuously advancing the security of Pixel devices. We have been focusing on hardening the cellular baseband modem against exploitation. <a href="https://security.googleblog.com/2023/12/hardening-cellular-basebands-in-android.html">Recognizing the risks</a> associated within the complex modem firmware, Pixel 9 shipped with <a href="https://security.googleblog.com/2024/10/pixel-proactive-security-cellular-modems.html">mitigations</a> against a range of memory-safety vulnerabilities. For Pixel 10, Google is advancing its proactive security measures further. Following our previous discussion on <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html">"Deploying Rust in Existing Firmware Codebases"</a>, this post shares a concrete application: integrating a memory-safe Rust DNS(Domain Name System) parser into the modem firmware. The new Rust-based DNS parser significantly reduces our security risk by mitigating an entire class of vulnerabilities in a risky area, while also laying the foundation for broader adoption of memory-safe code in other areas.</p> <p>Here we share our experience of working on it, and hope it can inspire the use of more memory safe languages in low-level environments.</p> <h3>Why Modem Memory Safety Can&#8217;t Wait</h3> <p>In recent years, we have seen increasing interest in the cellular modem from attackers and security researchers. For example, Google's Project Zero <a href="https://googleprojectzero.blogspot.com/2023/03/multiple-internet-to-baseband-remote-rce.html">gained remote code execution</a> on Pixel modems over the Internet. Pixel modem has tens of Megabytes of executable code. Given the complexity and remote attack surface of the modem, other critical memory safety vulnerabilities may remain in the predominantly memory-unsafe firmware code.</p> <h3>Why DNS?</h3> <p>The DNS protocol is most commonly known in the context of browsers finding websites. With the evolution of cellular technology, modern cellular communications have migrated to digital data networks; consequently, even basic operations such as call forwarding rely on DNS services.</p> <p>DNS is a complex protocol and requires parsing of untrusted data, which can lead to vulnerabilities, particularly when implemented in a memory-unsafe language (example: <a href="https://nvd.nist.gov/vuln/detail/cve-2024-27227">CVE-2024-27227</a>). Implementing the DNS parser in Rust offers value by decreasing the attack surfaces associated with memory unsafety.</p> <h3>Picking a DNS library</h3> <p>DNS already has a level of support in the open-source Rust community. We evaluated multiple open source crates that implement DNS. Based on <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html#:~:text=Existing%20Crate">criteria shared in earlier posts</a>, we identified <a href="https://crates.io/crates/hickory-proto">hickory-proto</a> as the best candidate. It has excellent maintenance, over 75% test coverage, and widespread adoption in the Rust community. Its pervasiveness shows its potential as the de-facto DNS choice and long term support. Although hickory-proto initially lacked <code>no_std</code> support, which is needed for Bare-metal environments (see our <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html#:~:text=Bare%2Dmetal%20Environments">previous post</a> on this topic), we were able to add support to it and its dependencies.</p> <h2>Adding <code>no_std</code> support</h2> <p>The work to enable <code>no_std</code> for hickory-proto is mostly mechanical. We shared the process <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html#:~:text=Porting%20a%20std%20Library%20to%20no_std">in a previous post</a>. We undertook modifications to hickory_proto and its dependencies to enable <code>no_std</code> support. The upstream <code>no_std</code> work also results in a <code>no_std</code> URL parser, beneficial to other projects.</p> <ul> <li><a href="https://github.com/hickory-dns/hickory-dns/pull/2104">https://github.com/hickory-dns/hickory-dns/pull/2104</a></li> <li><a href="https://github.com/servo/rust-url/pull/831">https://github.com/servo/rust-url/pull/831</a></li> <li><a href="https://github.com/krisprice/ipnet/pull/58">https://github.com/krisprice/ipnet/pull/58</a></li> </ul> <p>The above PRs are great examples of how to extend <code>no_std</code> support to existing std-only crates.</p> <h2>Code size study</h2> <p>Code size is the one of the factors that we evaluated when picking the DNS library to use.</p> <table border="1" cellpadding="8" cellspacing="0" style="border-collapse: collapse; width: 100%;"> <tbody> <tr> <td rowspan="3" style="width: 25%;">Code size<br>by category</td> <td>Rust implemented Shim that calls Hickory-proto on receiving a DNS response</td> <td style="width: 15%;">4KB</td> </tr> <tr> <td>core, alloc, compiler_builtins<br>(reusable, one-time cost)</td> <td>17KB</td> </tr> <tr> <td>Hickory-proto library and dependencies</td> <td>350KB</td> </tr> </tbody> </table> <br> <hr style="border: 0; border-top: 2px solid #f0f0f0;"> <br> <table border="1" cellpadding="8" cellspacing="0" style="border-collapse: collapse; width: 100%;"> <tbody> <tr> <td style="width: 25%;">Sum</td> <td></td> <td style="width: 15%;">371KB</td> </tr> </tbody> </table> <p>We built prototypes and measured size with <a href="https://security.googleblog.com/2024/09/deploying-rust-in-existing-firmware.html#:~:text=Build%20Optimizations">size-optimized settings</a>. Expectedly, <code>hickory_proto</code> is not designed with embedded use in mind, and is not optimized for size. As the Pixel modem is not tightly memory constrained, we prioritized community support and code quality, leaving code size optimizations as future work.</p> <p>However, the additional code size may be a blocker for other embedded systems. This could be addressed in the future by adding additional feature flags to conditionally compile only required functionality. Implementing this modularity would be a valuable future work.</p> <h3>Hook-up Rust to modem firmware</h3> <p>Before building the Rust DNS library, we defined several Rust unit tests to cover basic arithmetic, dynamic allocations, and <a href="https://doc.rust-lang.org/nomicon/ffi.html"><code>FFI</code></a> to verify the integration of Rust with the existing modem firmware code base.</p> <h2>Compile Rust code to staticlib</h2> <p>While using <code>cargo</code> is the default choice for compilation in the Rust ecosystem, it <a href="https://security.googleblog.com/2021/05/integrating-rust-into-android-open.html#:~:text=No%20nested%20build%20systems">presents challenges</a> when integrating it into existing build systems. We evaluated two options:</p> <ol> <li>Using <code>cargo</code> to build a <a href="https://doc.rust-lang.org/beta/rustc/command-line-arguments.html#--crate-type-a-list-of-types-of-crates-for-the-compiler-to-emit"><code>staticlib</code></a> before the modem builds. Then add the produced staticlib into the linking step.</li> <li>Directly work with <code>rustc</code> and integrate the Rust compilation steps into the existing modem build system.</li> </ol> <p>Option #1 does not scale if we are going to add more Rust components in the future, as linking multiple staticlibs may cause <a href="https://github.com/rust-lang/rust/issues/44322">duplicated symbol errors</a>. We chose option #2 as it scales more easily and allows tighter integration into our existing build system. Our existing C/C++ codebase uses <a href="https://pigweed.dev/">Pigweed</a> to drive the primary build system. Pigweed supports Rust targets (<a href="https://cs.opensource.google/pigweed/pigweed/+/main:pw_build/rust_library.gni;drc=87f7abc323e345dd2729d5039a7ee0ee49c2fd56">example</a>) with direct calls to <a href="https:

Indicators of Compromise

• cve — CVE-2024-27227

Entities