From the link- "In the current early stage of the project, GrapheneOS provides production releases for the Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3 and Pixel 3 XL. It will support other devices in the future, but devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventually be engaging in hardware and firmware level improvements rather than only offering suggestions and bug reports upstream for those areas."
A component being on the same die as the CPU doesn't mean that it isn't isolated. The SoC components in Snapdragon chips have IOMMU isolation. In modern computers, including smartphones, there are many components inside and outside SoC with memory access. A component being on the SoC is orthogonal to whether it has direct memory access. Direct memory access is supposed to be contained properly by an IOMMU, and that's the case for most of the components in the devices targeted by GrapheneOS. It's one of many kinds of hardware / firmware security properties that's going to play a substantial role in researching and choosing devices as targets.
Research is currently ongoing into choosing at least one decent low-end device with the least security compromises. There's no way to avoid losing some of the fancier hardware security features like the HSM because they aren't offered. The expectation is still that all the basic hardware / firmware security features are intact, which includes a decent IOMMU implementation, verified boot / attestation, at least a TEE-based hardware keystore (if they don't have a nicer HSM implementation like the high-end targets), etc. Many of the baseline security properties are tied to the SoC, including the IOMMU implementation for SoC components. Device vendors and the peripheral hardware vendors (like Broadcom for Wi-Fi) end up responsible for properly setting up IOMMU containment for peripherals, and that's often where the ball is completely dropped. There are often problems tied to where there are boundaries between organizations because there's often a lack of responsibility taken for these things. SoC security is unavoidably something that the SoC companies are responsible for handling, but issues like properly containing the Wi-Fi SoC can end up relegated to being treated as someone else's problem by every company involved.
May have been an issue in the past. Daniel claims that modern Pixel devices (among others) use IOMMU to control which memory segments the baseband device can access, and if implemented correctly it should only allow what is necessary for device->driver communication.
Of course that has never and will never receive any security updates. So although iommu isolation is good, it may not help much if there's a whole other OS hacked that can initiate its own network connections and futz with any traffic, eg, deny main OS updates until it can attack it via an unpatched vuln. TLS is good but it'd only take one hhtp connection through unpatched webview.
The cellular, Wi-Fi / Bluetooth and NFC radios do receive firmware security updates. GrapheneOS isn't going to support devices without proper security support, which includes ongoing maintenance and security engineering / research for the firmware and drivers.
Focusing on the cellular baseband is missing the bigger picture. There are dozens of computers in modern personal computers running their own operating systems. Cellular basebands are very directly comparable to the Wi-Fi SoC. It's a mistake to think that the same things don't apply to Wi-Fi, especially when on so many devices it's much less contained than the cellular baseband. I'd recommend checking out https://googleprojectzero.blogspot.com/2017/04/over-air-expl... which is about exploiting the Wi-Fi SoC older generation device, which then provides full direct memory access since it wasn't meaningfully contained by the IOMMU. It was a configuration and driver coding issue, as the hardware was entirely capable of containing it but was unfortunately not set up to do it.
> Security focused and Android in the same sentence?
The whole point behind it is working on a new mobile OS, while providing Android app compatibility by using the Android Open Source Project. As the page states, the long-term goal is to turn AOSP into an application layer while moving away from entirely depending on Linux for low-level security since it's a huge liability / weakness. It already isn't 'Android' since it makes changes deviating from what's required to be Android (the Compatibility Definition Document and Compatibility Test Suite). The goal is practical compatibility with Android applications rather than conforming to what's requiring to be Android.
> All I can say is good luck with various firmware, custom services and drivers.
Hardware, firmware and drivers aren't an OS specific issue beyond drivers being tied to Linux. There's barely any content on the site yet, but it does cover how important it's going to be to make careful choices about which hardware to support in the device support section. It talks about how much of the privacy and security is tied to hardware capabilities and security support.
Every US company has to comply with lawful US government orders if they're going to continue operating. I highly recommend reading carefully through the details on the page you linked. It doesn't only apply to a few companies. It's very difficult to fight the government even in cases where it's arguably unconstitutional, etc. You have to assume that all US companies are going to comply with US warrants to obtain information, including when those warrants come from a secret court with a gag order.
There were consequences to the US passing draconian surveillance laws like the Patriot Act and the updates to it. Companies / organizations and individuals based in the US are subject to those laws. Many other countries have similar or even more oppressive laws when it comes to these things.
A company being based in for example France doesn't mean that the same kind of things don't apply.
If you don't want data to be subject to warrants requesting the information from companies, you need to either avoid having your data there or make sure it's encrypted with a key that the company doesn't have. End-to-end encryption is important. The companies could also have the data exposed by a malicious insider or a data breach. Many countries will happily demand the key from you and then treat you as a criminal for not turning it over but that doesn't work for mass surveillance.
