Isn't all of this obvious for a modern C or C++ codebase? Is the state of Android baseband so bad that these are useful suggestions? Are they at least properly ring-fenced from the host CPU/RAM these days?
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.
> 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.
I agree. I couldn't see much of a point in the techniques discussed when there's a huge elephant in the room, and you can't fix it, so I thought I was missing something obvious.
I wasn't: it's just security theater, doing something for the sake of doing something, while there's a big pink elephant in the room you should not look at:
> the IOMMU refuses to allow the OS to restrict the baseband processor's view into system RAM.
And I can't find any valid technical reason for that elephant to be in the room.
There shouldn't be limitations for accepting IOMMUs: "be liberal in what you accept and conservative in what you send"
> Some phones straight up admit the baseband is actively hostile and only communicates with it via serial
That looks like a fair assumption. You wouldn't have daemons listening as UID 0 on all ports, accepting then running the random binaries they get, so why would you magically assume it's ok to do the exact same but with baseband instead of a daemon?
> (which leads to poor performance, but a secure phone)
Can you recommend some phones?
I wanted to get a better understanding of the stack so I bought an original pinephone, with the grand plan of installing arch on it (for fun!)
Graphene recommends a modern pixel. If they can properly restrict memory access on those phones and the baseband doesn't have any direct access to the mic via analog signal or similar, then it probably can't listen in on either incoming or outgoing communication, that should all be encrypted before it hits the memory right? You could still be located and identified, but they don't need to compromise your baseband for that.
This could be old info but I believe the Baseband chipset has its own microphone in addition to access to the user mics for the purposes of signal processing.
This was a stink years ago and part of the GSMK product development. AFAIK GSMK is the only commercially available product to have a baseband firewall and their own stuff running to deal with this
Arguably, any system that uses a Qualcomm SoC is not secure: either they do it on purpose, or they truly are incompetent, or it is a mix of both. No Qualcomm phone I've ever owned I've been truly happy with from the SoC SDK perspective (makes the job of community ROMs a thousand times harder).
I do consider the Pinephone and Pinephone Pro secure, however. It doesn't use Qualcomm, and the broadband SoC is an isolated part. Allwinner and Rockchip do not have the security nightmare track record that Qualcomm does. They also ship with Postmarket instead of an Android that isn't security focused, which is nice.
The only problem with Allwinner and Rockchip is they are both Chinese companies that may be tampered with by the Chinese government. Qualcomm and Mediatek just have a record, today, of security flaw after security flaw.
The new Samsung-made SoCs in the new Pixels are also an interesting choice. They do not use the Samsung TPM, instead opting for Google's newest version of the Titan TPM. Shortly after the Pixel 6 came out, Google Project Zero issued a story about the Samsung TPM having security issues. Hmmmmmmmmmmmmmmmmmmmmmmmmm.
> I do consider the Pinephone and Pinephone Pro secure, however. It doesn't use Qualcomm, and the broadband SoC is an isolated part.
Good, I'll play with my pinephone then! I didn't want my efforts to be wasted if I discovered some horrible security hole that I would find as distracting as this obvious huge elephant in the room
> The only problem with Allwinner and Rockchip is they are both Chinese companies that may be tampered with by the Chinese government.
I do not believe this is a likely problem. And even if it was, "not for me": I already have a few eink android Chinese devices so I'd be toast anyway, so it shouldn't influence my decision.
> Qualcomm and Mediatek just have a record, today, of security flaw after security flaw.
I see that and I find it concerning, so I'd rather take my chances with something I can explore, see the flaws and limit them, than something that doesn't let me do that.
BTW I love how they are more flexible that US devices, letting me root and change their mtd content! Check the boox and bigme devices if you are interested in linux on baremetal color eink, yet with full control.
