> - there are only three big players in town: Qualcomm, Mediatek and Samsung, and the latter is pretty rare to find outside of Samsung's own devices

For basebands yes. I'll complete this for a quick overview for IMS/VoLTE, which is often in baseband, but not always. (And VoLTE is at least partly what the article is about, and the last public Pixel remote flaw was caused by VoLTE)

Just to give a quick approximate overlook:

- If you're on a Verizon-branded device, Verizon probably made their own IMS implementation mandatory [1]

- If you're on a Samsung or LGE-branded device (no matter the SoC), they use their own IMS implementation [1]

- If you're using a non-Samsung-branded Samsung Silicon device (=SLSI: Pixels, Moto One Action and few others), they use a different IMS implementation than the IMS Samsung uses in their smartphones

- In other cases, you're indeed likely using the IMS/VoLTE implementation provided by the baseband/SoC vendor

As far as I know, the implementations I've marked with [1] are at least partially [2] done in userland in application processor rather than in modem, but it's hard understanding really. The ones that are not marked with [1] are in modem afaik.

[2] Partially meaning the annoying protocol stuff, but audio encoding/decoding + RTP encapsulation might remain in hardware

It's actually strictly worse: even if they had an IOMMU and the drivers were implemented correctly, phone vendors provide remote access tools as part of their firmware stack (e.g., see https://www.fsf.org/blogs/community/replicant-developers-fin...). To reiterate one of the other commenters, as long as users don't control what code runs on the baseband, they do not in fact have ownership of the device. The same holds for anything else that has a baseband (such as most modern cars). This sentiment is publicly communicated by telco's and manufacturers and convenient for regulators.

At least modern Google Pixel phones have an IOMMU (https://grapheneos.org/faq#baseband-isolation)

Take a few steps back, the obvious problem is that all phones are chock full of mysterious black boxes that the owner of the device has zero say over.

Android has the problem of being too open to prevent backwards implementations and shitty, vulnerable, and bug prone code, but not open enough for anyone with the incentive to fix those issues to actually be allowed to fix them.

I see the eventualities to be either Google locks down android significantly, and the market shifts to something more akin to Nvidia's board partner model, or, it opens way up, and device manufacturers open source their implementations of various system devices in order to crowd source fixes/improvements/etc. The former is much more likely than the latter, but, as a consumer, the latter would be preferable.

I'm just guessing here; but the reason why it's not implemented in userspace, not written in Rust, not using IOMMU, BP is allowed full DMA, the system is split into AP and BP in the first place, etc etc, is probably because of lags those stuffs introduce - difficulty of meeting and maintaining required realtime constraints.

ALL of those desktop-derived event driven technologies, with deep call stacks and abusive use of interrupts, tend to run NOT like a marathon runner, but like an attention deficit man, and the latter is how you get choppy audio.

IIUC, Nokia in '00s already used an architecture that baseband OS and application OS(Symbian) would run on the same CPU, with RTOS below the application OS forcing regular switch to baseband or something, because baseband code is synchronized to physical IRL time, managing physical phenomena, and the user, can wait.

If anyone's going to move phone signaling and audio processing to AP, they'll have to first show the embedded guys that their fancy stuff is better than the existing realtime stuff, and is not an elaborate prank. Which, I think, isn't easy. I mean, one of news for Raspberry Pi 5 was addition of a programmable I/O processor for realtime/low-level tasks, not removal of.

Hey, that looks really cool. I've been wanting to mess around with this stuff on PinePhone, which is in a unique position here since there are third-party images for the baseband which are mostly open source[1].

I've been especially interested in trying to reverse engineer what's going on with Google Fi on Android, but it is definitely a bit over my head, given that until recently I didn't even really know what an AT command was :) I'm guessing since it's Google the carrier stuff is mostly for fallback and all of the actually interesting stuff is done using protobufs over a data connection. (Fi is also interesting because you can make phone calls on the web over WebRTC. I wonder if that's some kind of gateway to SIP, or what.)

[1]: https://github.com/the-modem-distro/pinephone_modem_sdk

(Note: I didn't dig deep enough, so it wouldn't surprise me if the blobs in this are actually where the interesting stuff happens, but it's still probably a great base for experimentation nonetheless.)

Not to take away from your excellent work, but what the hell is the point of VoWifi ?

Why not just handle this with a well tuned user space app that runs on udp/whatever over any network connectivity you have already, whether it's wifi/cellular/pigeon carrier.

It seems like its an entirely US-centric thing, motivated by a] cost savings from not using data on the cell network (not a problem for most of the world who have unlimited data plans cheap enough for everyone to afford) and b] some kind of vendor feature contest/lock-in type incentives.

What is the selling point of it, I don't get it. WhatsApp/Facetime/Signal or similar voice calls are not perfect, they obviously do introduce some extra latency and inefficiencies compared to using that lower level data pipe, but it just strikes me as a very strange avenue for people to be going down with very marginal benefit (efficiency) but a ton of extra work.

EDIT: Btw if its not clear, I fully agree with you that it, whatever it is, should be in userspace as much as possible, and as an open standard, I'm just trying to figure out why this stuff has been introduced in this way at all.

I've played with doubango for some time trying to get it to work against the flavor of IMS used in VoLTE / VoWiFi, and it is not all that close to it, even with various hacks applied from https://gitea.osmocom.org/ims-volte-vowifi/doubango/commits/... in which I tried to add a Linux kernel IPsec plugin as well as various other bits and pieces.

That looks great! I have a pixel 4xl that will not allow enabling VoWifi. (Maybe old sim card, maybe Graphene.) As you mentioned, great for other builds. PinePhone, etc. Going to try...

This particular comment became the first Google search result (or 'featured snippet') for me for "What is Android Baseband" -- weirdly claiming to be posted four hours ago when this comment was two hours old.

That is mindblowing to me. Full credit to the poster for becoming the canonical answer, but I'm not sure how I feel about Google picking comments without even some kind of page-rank-weighted attempt at deciding what is 'best'.

The device drivers for these baseband processors really should be run inside virtual machines. Most modern processors support IOMMUs [1], and assuming that (hopefully) modern cellphone processors have IOMMU support, the operating system should be updated to running device drivers in an isolated container or VM.

With Linux not being a microkernel there’s a high likelihood the device driver expects to run in kernel mode. We probably will need to have a little a Linux VM containing the driver, and create a system that propagates its I/O back to the host. It’s a lot of overhead, but I’m not sure if there any other way of ensuring secure device drivers on Linux.

[1] Ancient device drivers expected full unrestricted DMA, i.e. full unlimited read/write access to RAM. But IOMMUs (VT-d on Intel) let us pretend to give such device drivers full DMA while isolating them.

> , it can lead to complete device compromise.

lile they had on the flagship pixels just 8mo ago.

the csv google downgraded the severity because there was a work around of "disabling 5/4g" in a market that offset 3g. heh.

> When baseband firmware is compromised, it can lead to complete device compromise.

I believe that’s generally only still true for Android and fixing that is what this is talking about. I don’t actually know but I recall when I worked at Apple many years ago that the baseband was firewalled already for this exact reason.

Edit: can’t find any reports of a baseband compromise for iPhones although I wouldn’t rely on a 30 second DuckDuckGo search to state something definitively.

It can but doesn't necessarily, right? There's a variety of interconnect and IOMMU architectures here, so it's not a given that a baseband processor has or is one step away from unrestricted access to the whole platform.

Is there any way to isolate or sandbox it, so that the rest of the phone/device is not compromised?

The Pixel lineup uses Samsung modems.

it probably is, but you won't get the usual academic work for free as you get with more common platforms.

It isn't about "sufficient contact". Google knows exactly who to call at any of these companies, and those people will pick up the phone when they see Google is the one calling.

Qualcomm actively botches the security of their products as per request of many governments.

The purpose of the letter is to openly shame these companies without directly accusing them of foul play, instead of gently painting them with the brush of mere incompetence, mere lack of knowledge how modern tooling works.

The problem is it isn't "Android baseband", it doesn't run on the CPU that Android does at al. Instead, an entire second whole computer (not even a "microcontroller", in many cases they are just as powerful per-core as your real CPU) that runs a closed source realtime OS that Google (et al.) has zero visibility into.

Some phones straight up admit the baseband is actively hostile and only communicates with it via serial (which leads to poor performance, but a secure phone). Some phones, such as any using a vanilla Qualcomm Snapdragon setup of any generation simply don't care: the baseband firmware has more holes than a slice of swiss, and the IOMMU refuses to allow the OS to restrict the baseband processor's view into system RAM.

This is a known attack vector used by state sponsored actors, including the US breaking into the phones of so-called "drug lords" to ease drop on them live from their own phones , without a call being active.

Until basebands are mandated to be FOSS for security and safety reasons, Google is just moving the chairs around on the deck of a sinking ship.