Hardening cellular basebands in Android
Android’s cellular “baseband” processors are emerging as a major security weak point, since they run opaque, proprietary firmware with deep access to hardware and sometimes system memory. Commenters argue that Google’s proposed hardening techniques (sanitizers, safer toolchains) are incremental at best as long as basebands remain closed, poorly isolated via IOMMU, and controlled by a small oligopoly of vendors constrained by patent and regulatory dynamics. Several point to more radical changes—FOSS baseband stacks, moving complex protocols like VoLTE/IMS into auditable userspace code, and stricter hardware isolation—as the only way to meaningfully limit remote compromise risk.
Baseband architecture and risk profile
- Basebands are separate processors with their own firmware and OS, often as powerful as the main CPU and largely opaque to Google and users.
- Compromise of baseband firmware can enable full device compromise if it has unrestricted memory access; some report real-world use by state actors to eavesdrop.
- Others note that impact depends on interconnect and isolation: some platforms use MMU/IOMMU so baseband code execution mainly exposes radio traffic and location, not full system.
Isolation, IOMMU, and DMA
- Many commenters argue that proper IOMMU use and treating the baseband as untrusted are more important than incremental compiler hardening.
- Some phones allegedly wire basebands directly to system RAM or PCI without IOMMU, making exploitation “game over.”
- Modern Pixels and iPhones are cited as examples where IOMMU/MMU are used to contain DMA, though details and completeness are debated.
- There’s advocacy for running baseband drivers in VMs or isolated kernels; others note this is already partly happening or that hardware/RT constraints complicate it.
Proprietary ecosystem, patents, and “security theater”
- Strong sentiment that closed, non-user-controllable baseband firmware is the core problem; vendor “remote access” backdoors are mentioned.
- Oligopoly of Qualcomm/Mediatek/Samsung and patent/pool politics are blamed for lack of competition and slow security improvements.
- Some suspect deliberate weakening under government pressure; others suggest incompetence and misaligned incentives. Evidence is acknowledged as largely circumstantial.
- Several see Google’s hardening advice as useful but ultimately limited “security theater” without FOSS basebands and true isolation.
Shifting functionality out of the baseband
- One thread argues the real fix is to stop putting complex stacks (IMS/VoLTE/VoWiFi, SIP, TCP/IP, DNS, XML parsing) inside basebands.
- Proposed model: implement IMS/VoLTE/VoWiFi as open-source, userspace apps (example Kotlin IMS project) with minimal cooperation from a “dumb” modem.
- This is seen as improving security, debuggability, and feature agility, though some note real-time and QoS constraints and remaining parts that must stay on the modem.
Devices, projects, and experiments
- PinePhone/PinePhone Pro, non-Qualcomm SoCs, and some Pixels are discussed as relatively better for experimentation or isolation; others question their IOMMU support.
- Open baseband efforts (e.g., Osmocom, PinePhone modem images) are noted, but commenters say modern 3G+/5G modems remain mostly sealed black boxes.