I also read between the lines something like "don't be surprised if we start to make our own chipsets and drivers, because current vendors can't be trusted to do a good job".
Even Apple failed at that, despite having bought out Intel's modem division and there being no other company coming even close to Apple's demand of hoarding knowledge in-house.
The problem is multifold:
- RF of any kind is extremely complex
- RF of any kind that is to be certified in virtually all countries on this rock, with providers with infrastructure from 2G shit that never got upgraded since the 90s to hyper-modern OpenRAN is even more complex simply due to all the cert and testing effort required
- making that RF stuff power efficient is the utter end game
- mobile communications standards on their own are a horrid, horrid mess to implement, not made easier by some of the specs being decades old and never intended to coexist in a world where a single device can run 30 gigabit a second...
- patents, so many patents, because of course it's a global standard that a) isn't open and b) everyone and their dog wants to profit off of
- on top of that come legal aspects: not just the certification requirements, but also lawful intercept and stealth ping stuff, or having to secure the device so that enterprising hackers can't readily turn it into an SDR, jammer or sniffer...
> - patents, so many patents, because of course it's a global standard that a) isn't open and b) everyone and their dog wants to profit off of
This is the only real problem. The other problems are challenging but surmountable engineering issues (which Apple already had solutions to, thanks to their Intel-modem acquisition).
There are plenty of Chinese basebands that work (code quality and security aside), because the CCP told Qualcomm to get bent in 2015.
All of the issue you described are specific to basebands, not all "chipsets and drivers", and this article is talking about exploits in DSPs, not basebands. Moreover, AFAIK the baseband (or more specifically the modem) is separated from the application processor on both iPhones and Pixels, so a baseband 0day allowing you to take over the entire phone is already unlikely.
For what it's worth, the DSP this driver talks to is the same type of DSP used in Qualcomm basebands.
However, there's actually no strong relevance to DSPs at all here; it's just a broken DMA/ION-shared-memory driver that happens to be the one that talks to a DSP. There are lots of these in most Android board support packages.
> separated from the application processor on both iPhones and Pixels
Across an interface with drivers! Quite a few baseband drivers are exploitable from both sides of the interface.
> so a baseband 0day allowing you to take over the entire phone is already unlikely.
The baseband has to talk with the main SoC though by some way, and wherever there are interfaces, so are drivers and associated bugs. And usually you get the baseband and main SoC from the same company, so same engineering culture. It's not like shoddy development isn't just happening on the baseband BSP side.
> All of the issue you described are specific to basebands, not all "chipsets and drivers", and this article is talking about exploits in DSPs, not basebands.
Power efficiency, patents and legal compliance crap also impact the main SoC/chipset side.
> Even Apple failed at that, despite having bought out Intel's modem division and there being no other company coming even close to Apple's demand of hoarding knowledge in-house.
The upcoming SE going on sale in 2025 is set to have the Apple modem.
For compute offload, Google has indeed done that - the Tensor chips have Google's TPUs instead of Qualcomm DSPs.
Both on these TPUs as well as on pre-Tensor hardware that had Qualcomm DSPs, Pixels would not allow apps access to the kernel interfaces. Access would be blocked or mediated via a separate service process ('binderized HAL').
(Some) OEMs have repeatedly opened access to these kernel interfaces in order to trade security for performance.
