Neither of the devices is open hardware and neither has open firmware, despite misconceptions created by misleading marketing. The Librem 5 is deliberately locked down to prevent updating the firmware. Neither is close to the security requirements for official GrapheneOS support.
Conversation
See grapheneos.org/faq#device-sup for an overview of device support including the requirements for official support. We can't provide official support for insecure devices with vulnerabilities that can't be patched. Similarly, the hardware needs to provide the standard hardware-based
1
1
6
security features including the hardware-backed keystores used by the OS and apps, support for real verified boot and attestation, modern mitigations, proper IOMMU integration / setup for the components, hardware key derivation support, Wi-Fi anonymity beyond just MAC rand, etc.
3
1
7
But to get all those you also have to trust yet another closed stack of components and piles of privileged binary blobs you have to sort through tediously on every single new device.
All current options suck in very different ways.
2
The Librem 5 and Pinephone are closed hardware with closed firmware. The complexity in the entirely closed source SoC and other hardware components / firmware completely dwarfs the complexity in userspace libraries. You're also grouping things that are open source in with blobs.
2
Yeah most of the vendor blobs can be compiled from open code. With a ton of work AOSP can be made tolerable but as it is major corners are cut due to lack of cycles.
All Pixel devices are closed hardware too.
Mac address rand and some security/privacy features can be ported.
1
You're misrepresenting this as something to do with AOSP when it has to do with the hardware. AOSP runs on hardware using entirely open drivers already. Pixel 3 can largely be supported using open drivers: linaro.org/blog/dragonboa. You're just more interested in causing harm.
2
You skipped over what I actually talked about a chose to make misleading claims and spin instead. You respond to what I said about MAC randomization ignoring that the point was it doesn't work by itself. Not sure how you expect to port hardware security in software either.
1
I only cherry picked Mac randomization. IOMMU and lack of secure boot can't be solved on librem/pinephone. That is clear.
I am just trying to find the least bad path given very limited time.
If Pixel 4 is a sign of things to come... AOSP deblobbing is only going to get harder.
1
You missed the point about MAC randomization which is that doing in software on hardware that doesn't provide support for Wi-Fi anonymity doesn't work. It wasn't until the Nexus 5X and first generation Pixels got firmware support for anonymity that it became possible to have it.
1
Also, again, you're confusing issues tied to support for hardware with any OS with an issue with AOSP as a generic OS. GrapheneOS ultimately does not want to support Pixel devices. Those are our development devices right now. When better hardware exists, we won't support Pixels.
Pixels are currently by far the most secure hardware available with support for installing another OS like GrapheneOS. There are many ways in which that is the case. There are a lot of other options available, and most are far worse. Secure devices tend not to support other OSes.
That is a reasonable stance and I respect it. If there is any chance of less blob-ridden hardware on the horizon then I am all in back on team AOSP.
Trouble is until that time happens we all have touch security/time tradeoffs to make.
Keep up the solid work.
1
It seems we both at least agree there is no practical future for a user controllable pixel line. Pinephone and Librem 5 are even further from the mark hardware wise (but fewer OS blobs).
All current hardware is shit for security/privacy. We fundamentally agree there.
1
Show replies