[robotbikes]

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."

[Mediterraneo10]

Don’t even those phones feature a cellular modem that shares memory with the CPU? In that case, they remain insecure.

[strcat]

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.

[jtl999]

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.

I do think more research is needed.

[letstrynvm]

I was pretty amazed when I bought an MR200 lte-capable router that the LTE module actually runs its own personal Android discrete from the router cpu.

https://openwrt.org/toh/tp-link/archer-mr200#the_lte_modem

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.

[strcat]

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.