Headline & intro
For years, smartphone makers have armored Android and iOS while leaving one of the most critical components—the cellular modem—as a largely unexamined black box. With the Pixel 10, Google is quietly poking a hole in that box and sliding in something new: Rust. The company has grafted a Rust-based DNS parser into its modem stack, aiming to shut down an entire class of baseband exploits without rewriting decades of legacy code. This looks small and highly technical, but it’s arguably one of the most consequential security experiments in recent Android history—and it puts real pressure on modem vendors and regulators alike.
In this piece, we’ll unpack what Google actually shipped, why it matters far beyond Pixel owners, and how it fits into a broader industry pivot toward memory‑safe code.
The news in brief
According to reporting by Ars Technica, Google has shipped the Pixel 10 series with a modified cellular modem that offloads DNS parsing to a Rust component. The change follows multiple research efforts from Google’s own Project Zero team, which demonstrated remote code execution against Pixel modems—particularly Exynos-based models—over the network.
Instead of replacing the whole baseband firmware, Google targeted one of the riskiest pieces: the DNS parser, which must handle untrusted data and has historically been a rich source of memory‑safety bugs. Google integrated hickory-proto, an open-source Rust DNS library, then stripped it of standard-library dependencies so it could be compiled down and stitched into the existing C/C++ modem code.
The Rust addition reportedly increases modem firmware size by about 371 KB—acceptable for a modern smartphone baseband—and is designed so malicious DNS traffic cannot corrupt memory inside that Rust boundary. The Pixel 10 is the first device line to ship this approach, which Google hopes can serve as a template for other platforms.
Why this matters
Baseband attacks are the nightmare scenario security people struggle to explain to normal users. A compromised app or browser tab is bad; a compromised modem is worse. The baseband sits outside the main OS sandbox, talks directly to the radio, and often has privileged access to memory and hardware. Once it’s owned, traditional protections like app permissions, secure boot chains, and OS-level sandboxes may not help much.
So far, the industry has largely treated modems as untouchable vendor blobs. Qualcomm, Samsung, and MediaTek ship closed stacks implemented mostly in C and C++, optimized for real-time performance and backwards compatibility with 2G–5G networks. The result is predictable: big, complex codebases with the usual memory-corruption landmines.
Google’s Rust experiment is significant for three reasons:
- It proves incremental change is possible. You don’t have to throw away millions of lines of C to gain meaningful safety; you can move the most exposed parsing logic into a memory-safe language and create a hard boundary.
- It shifts responsibility upstream. By shipping a safer baseband on Pixel, Google is implicitly saying, "we won’t just wait for modem vendors to get their act together." That’s a strong signal to the rest of the Android ecosystem.
- It targets a real, abused attack surface. DNS parsing is exactly the kind of input-heavy, attacker-controlled component where Rust’s guarantees have outsized value. This isn’t a demo; it’s a fix for a specific, exploited class of bugs.
Winners are Pixel 10 users, of course, but also policymakers and other OEMs who now have a concrete example that "Rust in the modem" is not science fiction. The losers are vendors and integrators who’ve relied on opaque firmware and patch‑and‑pray cycles; the bar for "acceptable" baseband security has just moved.
The bigger picture
Google’s move fits into a much broader industry realization: most catastrophic vulnerabilities boil down to memory-unsafe code. Microsoft has said repeatedly that the majority of serious Windows bugs trace back to memory safety issues. The US NSA and other agencies are explicitly recommending memory-safe languages for new development. Linux now accepts Rust in the kernel. Android’s userspace has been quietly absorbing more and more Rust each year.
Basebands are late to this party precisely because they are so sensitive: real‑time constraints, proprietary stacks, and decades of 3GPP protocol cruft make vendors extremely conservative. That’s why Google’s approach—surgically introducing Rust into a critical parsing path without rewriting the whole stack—is interesting. It mirrors what we’ve seen in browsers, where components like Firefox’s and Chrome’s media or font parsers have been reimplemented in Rust or other safer languages and then isolated.
There’s also a historical echo here. Fifteen years ago, OS vendors began sandboxing the browser and carving off attack surfaces like PDF readers and media codecs. We now take that for granted. The modem has simply lagged, partly because manufacturers could claim that "it’s all handled by the chipset vendor." Pixel 10’s modem shows that excuse is expiring.
Apple is the silent comparison. Its iPhones also rely on extremely complex baseband firmware, and while Apple invests heavily in mitigations, the company hasn’t talked publicly about bringing Rust or equivalent memory-safe tech into its modem stack. If Google can demonstrate a measurable drop in modem CVEs on Pixels over the next few years, the pressure on Apple and Android OEMs alike will intensify.
Finally, this aligns with looming regulation. The EU’s Cyber Resilience Act and similar initiatives around the world are nudging vendors toward "secure by design" software. Memory-safe languages are a straightforward way to argue you’ve reduced whole classes of defects. A Rustified modem gives Google a strong story in that emerging regulatory landscape.
The European / regional angle
For European users, the modem is not just a security concern; it’s a sovereignty issue. Our phones connect to EU-operated networks, carry data protected under GDPR, and will increasingly be scrutinized under the Digital Services Act and upcoming cybersecurity rules. Yet the firmware that arbitrates those connections is often written and maintained far outside European oversight.
Google’s Pixel line has a modest market share in Europe, but it plays an outsized role in setting expectations. A Pixel 10 that advertises a "hardened modem" immediately creates an awkward question for other Android vendors, especially those pushing devices in privacy-conscious markets like Germany or the Nordics: why is your baseband still a fully opaque C blob?
European regulators and agencies such as ENISA have been talking more about supply‑chain security and secure development practices. Moves like this give them something concrete to point to. It’s entirely plausible that future EU certification schemes for smartphones or connected devices will treat the use of memory-safe languages in critical components as a positive—or even expected—criterion.
There’s also an industrial angle. European players like Nokia and Ericsson dominate network infrastructure, not handset modems, but the same 3GPP specifications apply. If handset vendors demonstrate that Rust-based parsers or protocol handlers can run in real time on constrained systems, that idea can bleed into radio access networks and edge equipment as well. European OEMs building niche or industrial devices—think automotive telematics, payment terminals, or IoT gateways—may find Google’s approach a useful blueprint: you don’t need to rewrite your RTOS, you can start by wrapping the most dangerous parsers.
Looking ahead
Pixel 10 is almost certainly not the end goal. It’s a pilot project.
If this Rust DNS component ships without major performance regressions or stability disasters—and we’ll know that over the next 12–18 months—Google will have a strong internal case to extend the model. Likely next candidates include other protocol parsers that deal heavily with untrusted input: SIP/VoLTE signaling, SMS, or even parts of 5G NAS/RRC stacks.
Two questions will determine how transformative this becomes:
- Do modem vendors participate, or does Google keep bolting things on itself? If Qualcomm, Samsung, and MediaTek embrace Rust or similar approaches in their own reference firmware, we could see a widespread shift across Android by the late 2020s. If not, Pixel may turn into a rare "secure island" while the rest of the ecosystem lags.
- Do regulators start to care specifically about baseband security? So far, most cybersecurity rules talk at a high level about "secure development" and "vulnerability management." Once there are concrete, shippable examples of safer basebands, policymakers may start asking why everyone else isn’t doing the same.
There are risks. A bit of Rust in the modem could become security theater if vendors use it as marketing while leaving other critical paths untouched. There’s also the danger of overconfidence: memory-safe languages drastically reduce certain bug classes but don’t eliminate logic flaws, protocol design issues, or side-channel attacks.
For technically minded readers, the signals to watch are:
- Future Android security bulletins: do we see fewer or less severe baseband CVEs on Pixel 10+ compared with older Pixels and rival devices?
- Vendor announcements: do chipset makers start mentioning Rust or "memory-safe" components in their roadmaps?
- Regulatory documents: do EU or US guidelines begin to reference memory safety in basebands explicitly?
If those needles move, Pixel 10’s modest 371 KB experiment will look, in hindsight, like the start of a much bigger migration.
The bottom line
By forcing a Rust-based component into one of the most fragile parts of the smartphone stack, Google is quietly rewriting expectations for modem security. This is not a silver bullet, but it’s a rare example of a major vendor taking on legacy embedded code rather than just wrapping it in more sandboxes. If Pixel 10 proves that "Rust in the baseband" is viable, how long before users—and regulators—start asking why every new phone doesn’t offer the same?
