GrapheneOS – A privacy and security-focused mobile OS with Android compatibility

Open source is a development model and doesn't have magical privacy and security properties. An iPhone is going to remain the best overall option for privacy and security for the near future, especially for users that aren't very technical. That's not really in spite of it being almost entirely proprietary but rather that's something quite orthogonal to it. GrapheneOS aims to provide a much more private and secure option down the road, but it's trying to do that based on merit rather than by claiming that being open source makes it better. Either way, the any ARM SoC is going to be a massively complex set of proprietary hardware / firmware / microcode. An open hardware SoC wouldn't provide inherently better privacy or security, and unlike software you wouldn't even be able to reproduce the build and verify that it matches what it's supposed to be. In reality, that provides very little for software, because sources are full of vulnerabilities and it being open source doesn't magically fix them. A maliciously inserted backdoor designed to be stealthy would be indistinguishable from those, and it's nearly impossible to know how many of the vulnerabilities being fixed in software were intentionally inserted backdoors, if any. A sophisticated attacker in a position to insert a backdoor into hardware or software could just use the existing vulnerabilities, and if they did insert a backdoor how would you distinguish it from one of those?

Components with DMA can be contained by IOMMU, and that's the industry standard today. However, you seem to be implying that backdoors are being inserted into non-CPU SoC components, and it's very hard to understand the threat model you're applying to this. Why would there even be a backdoor inserted into an SoC component like the image processor, which is contained by the IOMMU, rather than the CPU? These SoC components aren't third party components. They're on the same die as the CPU and come with it. That doesn't mean they can freely access all memory... but it does mean that supply chain attacks targeting them would generally be able to target the CPU instead.

If a hardware component is compromised, an attacker would target the driver and gain code execution in the Linux kernel via an exploit. The Linux kernel is a weak target (monolithic - no internal security boundaries, fully written in a memory unsafe language) and drivers are rarely well hardened against attacks from hardware since developers have a tendency to trust it and to not apply an adversarial model towards it as they do with userspace. They don't need unrestricted DMA access, and proper IOMMU setup keeps them from having that. Having DMA does not mean having full control over all memory. Not having DMA doesn't mean that the component is well isolated. Whether or not the component is on the same die is totally orthogonal to whether it has DMA access. These are common misconceptions, and are being abused by dishonest marketing to trick people.

> Android can give you privacy and enough security for most people.

Some of that is due to the improvements landed upstream based on the work in this project.

> This can't add much more as long as its running on the same devices.

I don't agree with that at all. It can't improve the security of firmware directly, but it can certainly improve the isolation of it by auditing and improving IOMMU configuration along with hardening the drivers. It also won't be supporting devices without decent IOMMU support and firmware security updates. The project has also reported various firmware security issues to the relevant companies over the years of the project, so that's an indirect way of improving them.

A large portion of the project will also be on app layer projects like https://github.com/GrapheneOS/Auditor usable on the stock OS and other operating systems. Auditor / AttestationServer support the stock OS on a bunch of devices, along with CalyxOS and GrapheneOS. Other apps will generally be more portable, but in this case it has to have a database of the verified boot key fingerprints and other device properties. The verified boot key is the only information included in the signed hardware attestation data that it can use to distinguish between devices which it needs to do in order to show the device model and apply different checks based on the device. That's why devices need to be added to Auditor one-by-one based on users submitting sample attestations with the app.

> It supports the Google Pixel range of phones only so far.

See https://grapheneos.org/#early-stage-of-development and https://grapheneos.org/#device-support. There's barely any content on the site, since it's so new, but this is covered pretty well. It does support other devices already. There's a difference between that and deciding to do all the work to provide official releases with seamless over-the-air updates covering all firmware, etc. along with porting all device-specific hardening work.

> So in order to get that is more secure and more independent from Google I have to buy a Google phone?

The goal is primarily implementing privacy and security improvements. It doesn't include Google services for privacy reasons, but that's not the purpose of the project. A project aiming to project AOSP with the baseline privacy/security intact and work to fill in gaps left by not having Play Services would be useful, but that's a tiny subset of what GrapheneOS is about. It's primarily about the privacy/security research and development work.

You can see that the GrapheneOS Auditor project supports a large range of devices already:

https://attestation.app/about#device-support

That's because it's quite easy to add support for each device one-by-one once users submit attestation samples with the app. The main list is for devices with the stock OS. It also supports CalyxOS and GrapheneOS on all their supported devices and will happily include other operating systems with verified boot and the security model intact. There are now a bunch of devices supporting verified boot with alternate operating systems.

There's a far larger app ecosystem for Android without Play Services than any other mobile OS. It's very odd to try to claim that it doesn't have that problem. Android is truly a Linux distribution too, and is truly free software. You can promote your preferred mobile OS without making misleading claims.

I feel google is really turning into Microsoft. These are the same anti open source talking points / FUD you’d see in the early 2000s.

pmOS should support the Librem 5 when it comes out, as well. We have several contributors working on them.