I'm not a mobile phone security expert but my feeling is that in the case of GrapheneOS - which target is probably high-profile people at risk of state actors et similia attacks - a zero-day in the closed source firmware from Qualcomm will probably screw you anyway.
I understand that you are anyway reducing the attack surface (now they need to target the modem firmware specifically), I understand the concept of security in depth and I also understand that by using GrapheneOS you are already placing mitigations for many other known and unknown attack vectors. But still...
All the devices that GrapheneOS supports implement a clear separation of the baseband and the CPU in the form of SMMU, ARMs version of IOMMU. So a zero-day in the baseband does not immediately screw you - unless the code on the CPU side also contains vulnerabilities or there is a major flaw in the SMMU implementation that somehow breaks isolation.
I probably explained myself in a shitty manner, I didn't try to downplay GrapheneOS efforts, and I should have kept my initial statement about "next best thing can create a false sense of completeness" as a generic remark and not specific to GrapheneOS, for which I don't have enough knowledge to know if it applies or not.
What that means is they can push malicious settings and configurations (Definitely) and probably malicious firmware to the handset at will. They don't need to code this, they buy the software packages from the usual suspects. Adversary simply needs to put a drt box or a hailstorm or what-not close enough to the handset to do the work.
The baseband can do a lot, it has dma (if I recall correctly) and can almost certainly screen look, and extract information from some but not all base bands. This varies.
GrapheneOS cannot really influence this, but hardened_malloc could conceivably help. What would be great is a bench firmware re-flash, but I don't want to do this every single day.
There's an IOMMU:
> Is the baseband isolated? > Yes, the baseband is isolated on all of the officially supported devices. Memory access is partitioned by the IOMMU and limited to internal memory and memory shared by the driver implementations. [...]
https://grapheneos.org/faq#baseband-isolation
> GrapheneOS cannot really influence this, but hardened_malloc could conceivably help.
They can and do, see above. But I don't see how hardened_malloc is related to the baseband doing DMA.
To answer your question, I thought it might just be slightly harder to extract secrets or exploit a running process directly. Thats all I was saying.
I do this on iOS I’m sure it’s do-able on GrapheneOS and hopefully on Android too.
Essentially, 5G is sort of a lie. Phones spend a lot of time exchanging information via 4g/lte, and just like 2g/3g and 3g/4g, there are simply downgrades that can be performed in the field, without getting too far into the weeds.
5G matters not for this.
And it's not only security - simple stuff like USB data off unless the phone is unlocked, native call recording, much enhanced user profiles (to separate data mining apps like Uber or Instagram from your financial affairs), etc.
And yes, it's about reducing the attack vector. On most other handsets you'll get most of the fixes 6 months or a year later. At best.
I do understand your point that people at risk of state level attacks might get a false surface level appearance of defence from this. But then anyone who's a target of state level attacks and is making OS decisions based on a surface level understanding of the tech is not going to have a good time anyway.
How about Pinephone with its partially freed baseband OS [0] or Librem 5 with its removable modem [1]?