News have only discussed Google desiring to design their own processors with a manufacturer like TSMC rather than working alongside Samsung for their Tensor processors. There is no suggestion to say everything will be inside one chip (which is also a very inefficient way to manufacture), but rather that Google desire to just have most of the components designed by them and manufactured. They would still be separate components, but, x86 platforms often have many physically separate processors manufactured by many OEMs but still receives many reports with firmware vulnerabilities in Wi-Fi, GPU, UEFI. Just having them as separate, removable components is not a security benefit.
A component being on a separate chip is indifferent to whether it's isolated. In order to be isolated, the OS needs to not trust the drivers of the hardware being used. Earlier generation supported devices before Pixels had Wi-Fi and Bluetooth implemented on a separate SoC and that was less contained in comparison to a Tensor Pixel device. The vast majority of attack surface in these components are down to the software, not the firmware. The issues in vulnerabilities like these are from the OS trusting hardware drivers too much.
Just because they also appear to be in one chip doesn't mean they all work like that. Newer Snapdragon Samsung devices put the baseband, processor and memory together in one component, but they are better described as being layered on top of one another to save space. Tensor processors are made in co-operation with Samsung and have a Samsung modem, while they are in separate locations on a motherboard it doesn't change the security, they're all connected to one another on the same board. An IOMMU is what the isolation is for.
Look at CVE-2023-28582... (long scenario)
It is easy to make up imaginary scenarios about exploitation but they are far from capable in reality. Your scenario would need a chain of exploits down to multiple layers of the OS or firmware to accomplish which is extremely unlikely. Even if memory corruption is present you would need additional work and further exploitation elsewhere to take advantage of the initial exploit in such a way that would allow a memory dump, exfiltrating that memory dump, making it undetectable, making it zero-click, reliable, and persistent (if you need it to be) among other things. Keeping such a sophisticated exploit chain is a gigantic pain with how much operating systems, drivers, and devices change, especially when you consider that many GrapheneOS changes are just security enhancements.
Android (and GrapheneOS) uses a defence-in-depth security model, there are security measures all around the OS from mandatory access controls, sandboxing, use of least privilege, anti-persistence measures, exploit protections and mitigations. GrapheneOS improving them further with hardened_malloc, adopting memory tagging, prevention of dynamic native code execution and a lot more makes this less reliable than you think it would. Sometimes bugs considered vulnerabilities from the upstream could have happened on GrapheneOS, but because of defences added elsewhere it made exploitation of that bug impossible even when the bug is present. Finding a bug and being able to exploit that bug are two very different things in terms of difficulty. Where an exploit successfully gets through one security measure, it has others it needs to break if it needs to have further goals than what the current exploit already met.
This reply isn't meant to downplay that specific CVE by any means, it is very bad, but you being able to even read that CVE is a good thing because it's proof the platforms are being assessed and scrutinized by security teams which forces additional security fixes and improvements. Many platforms and OEM's don't get this kind of eye and Google do a great job at this including by fixing vulnerabilities and crediting GrapheneOS by reports by GrapheneOS team members. We aren't worried about that.
I have seen the exploit of a AMD processor , a user in Linux can write a script and force the CPU using a CPU bug to dump the shadow password file which then can be bruteforced.
I think some similar attack style might be possible when all chips are replaced by one Google chip, no?
If it were (also unlikely), then it would be patched just like AMD had done. An exploit of a processor could be done regardless if they were separate chips or not, they wouldn't affect the difficulty but this is still a massive effort.
You will say its irrelevant but I think we should not forget what we are doing here. A free and open society requires human rights to be respected and discussion to be open, not censored and labeled as... (reply omitted)
I have removed some comments on your reply. It would be best to keep the thread about your current topic and bringing up such past events wouldn't be appropriate, I hope you understand.
GrapheneOS is open-minded although we are different from other projects work or behave. Certain topics get closed, deleted or redirected for a number of reasons. Misinformation isn't targeted out of malice, rather because their room for discussion disrupts the project's work. The objective of GrapheneOS is to provide a highly usable, private and secure mobile operating system while contributing to the mobile security/privacy community with bleeding-edge security research. The community GrapheneOS places itself in is unfortunately full of scammers, or at worse, criminals who try and sell the promise of mobile security and privacy and deliver neither of them. Many topics of interest can get discussed which mean little to nothing in the real world simply because these scammers use them as scapegoats or advertising speech to sell their false promise. Topics like open source software, global surveillance leaks, state-level threat actors become extremely ripe with people who believe completely wrong information about them because they read them from internet forums or these scammers rather than security teams and experts...
The approach we take on security/privacy innovation is a leading factor in the high quality of GrapheneOS' work, we don't believe in security theater and the about section can tell you more about our approach. If we focus too much on what people want to believe are real, then we wouldn't have any work done in protecting ourselves against what actually happens. It is better to eliminate entire categories of attacks or vulnerabilities than focus on one small example of a vulnerability.
As you have seen in our thread about vulnerability reports, it is worth noting that the companies responsible knew about GrapheneOS and had trouble with attacking it like they could with the stock OS. Our focus on what is actually happening protected people against real threats.