It's just a draft and is some pretty off the top stuff that I've just been putting together off the top of my head mostly, so bear with me for now.
Support for other devices is planned, but there are a few requirements for full support from Graphene OS. Rather than aim to try to support many devices, GrapheneOS seeks to support only the devices with the best security, and focus on specific devices to ensure that the most attention can be paid to the quality of the code, review, and testing. A more detailed answer is in the documentation at the entry under device support here: https://GrapheneOS.org/#device-support
Unconditionally yes.
Phones are powered by a system-on-chip, which includes all of its devices, such as the graphics processing unit, the cellphone's radio, and wifi and bluetooth chips, and other devices all integrated into a single chip. When Qualcomm releases a system-on-chip, they only agree to support it for a certain amount of time. Support for the system-on-chip includes things such as being delivered firmware updates for the cellphone's radios and graphics processing unit. The firmware is signed and validated with keys that only Qualcomm has, making Qualcomm the only entity that can update the firmware on the chip. Generally, Google negotiates with Qualcomm for a full three years of support, which dictates the lifetime of their phones.
Security researchers, script kiddies, advanced cybercriminals, and even intelligence agencies constantly discover new exploits on devices, some of which may include devices such as cellphone radios, WiFi antennas, and other components of a mobile phone, and vendor support in the form of firmware updates is required to allow the devices to keep pace with these exploits as they are discovered. Since only Qualcomm is capable of updating the firmware, this essentially means that once Qualcomm's support comes to an end, the security of these devices will no longer be keeping pace with the attacks on them. Even if software mitigations can continue to be backported to the existing kernels that run on the phones, this doesn't fix the problem of the devices themselves becoming vulnerable.
GrapheneOS supports devices that have strong modem isolation and support SMMU to limit memory access from the peripherals, but even though the peripherals are isolated from the host via IOMMU (the IOMMU virtualizes host memory access, so the host kernel is in full control over what the peripherals attached by DMA may read or write to), if the modem itself is still insecure, the potential exists for a compromised peripheral to deny service and thus compromise its availability or otherwise place itself in an advantageous position on the network even before the data has left the phone. Merely making the modem external does not address these problems. As a result, it doesn't make sense to continue backporting security patches from upstream to devices that are no longer supported. Doing so will also limit the amount of developer time that the project has to spend on other devices and advances in other areas.
The GrapheneOS project was founded to maximize the security that could be achieved via the Android Open Source Project. If the device cannot be used securely, it should no longer be used.
"Why does this project only support Pixels? I want to get away from Google, I don't want to have to buy Google to get away from Google!"
The irony of having to buy Google handsets to get away from Google is not lost on any of us. Unfortunately, not all Android handsets are created equal. "Android" is a series of compatibility specifications that OEMs need to meet in order to use the name and get the rights to be a part of the ecosystem, and how they meet it is largely left up to the vendors themselves. This leads us to consider the following:
- Google has been diligent with firmware security features, such as modem and radio isolation, and verified boot. Firmware sources are available (but non-free) for inspection. Additionally, the late-stage qualcomm bootloader which serves as the root of trust for the operating system is open-source. Many other vendors don't bother with any of this.
- The driver source code for the Pixel devices is open source. As drivers form a part of the trusted code base and are a security-critical software item, this makes them a no-brainer.
- Google makes extensive use of open standards and publishes tools and source code, documentation, as well as their toolchains and build system. Google has also gone the extra step of allowing customized Android Verified Boot Keying, which allows for us to utilize full hardware security features with an operating system (or system image) that is not our own. Many vendors don't do this and some even try to fight against it by designing their phones to use proprietary tools they do not publish to the public or don't release source code or support for. For example, Samsung and Sony are actively hostile to running other operating systems on their phones and incorporate E-Fuses into their handsets that will disable features on the handset permanently for the rest of time at the hardware level if the phone's bootloader is ever unlocked, some of which may even be vital security features.
- Google negotiates for three years of vendor support for the system-on-chip that powers the phone, and have a track record of being diligent with both firmware updates and driver updates. Some vendors don't negotiate for more than two, and some never supply firmware nor driver updates and don't even commit to supporting their handsets after the phone has shipped and they've walked away with your money. This is recklessly irresponsible, and GrapheneOS should be focusing on improving the security of the best devices, not picking up after other vendors' lack of care.
- Google Pixel Handsets starting with the Pixel 2 have Anti-Rollback mitigation and Insider Access Protection. The onboard HSM will not allow the firmware of the device to be downgraded to a legitimate previous version, which prevents the device being "restored" to an earlier and vulnerable version of the software or firmware. It also prevents the firmware from being upgraded in the absence of the user's password or pincode. This is designed to deter insider access attacks where an adversary may confiscate your phone, then in the absence of the password, use either legal or extralegal pressure to force the vendor to issue a malicious "update" to the device with validly signed but backdoored firmware. No other vendors offer this at this time.
GrapheneOS is released as source code and as a result it can be ported to other devices. However, it's up to the community to either maintain these devices, or find and pay other people to. The lead developer, Daniel Micay, would like to work more on deeper and more systematic improvements to GrapheneOS such as kernel-level exploit mitigations, low level code quality improvement, and safer handling of memory, which sets GrapheneOS apart from the other mobile operating systems. In the future, the project would like to take on deeper and more tasks, such as firmware security and even hardware. But there are a limited number of hours in the day, an even more limited number of hours he can spend on this, and maintaining more devices takes away from that.
Maintaining one device tends to involve a large amount of work, since each device uses its own kernel, its own drivers, its own firmware and many other software and firmware components that are specific to that one particular device. This all translates into a lot of work and it is not fair to assume only one person who is doing it on his own dime will be able to do everything to please the community, and give it away for free.
In an ideal, perfect world, Daniel Micay would have only one "Reference Implementation" of the operating system that he would maintain on his own, then the rest of the community would either contribute their time and effort to maintain other devices that would adhere to the same standards, or, if the community lacks in-house talent to do so, be able to hire and pay developers to maintain the devices they desire.
Device support for other devices won't happen if this doesn't, so, the old cliche applies: pull requests welcome.
"I want the project to further decentralize! Github is owned by Microsoft/The Men In Black/Aliens/T.H.E.M/Some Nebulous Government Conspiracy!"
GrapheneOS is developed using Git to control versioning. Git is a program that is installed to the hard drive of your computer as opposed to being operated as software-as-a-service, and can be made to operate or interoperate over ssh with a server of your choice, or even made to work over and send patches via E-mail. The actual source repositories of the operating system are stored on, inspected on, and worked on, on the hard drives of computers belonging to the developers. Source inspection from the lead developer, compilation and building takes place offline. This is about as decentralized as you can get.
Github is used as a friendly landing and social networking site by the project and isn't a trusted third party. It provides some nice features such as a WebUI which acts as a frontend to functions Git already has and helps to lower the barriers to entry for people new to the process, gives us cute avatars, social media profiles, and provides an easy issue tracker and bug reporting system and allows for new developers to quickly download and clone a copy of the code. All of these are features that are nice for the project, but it isn't used as an integral or trusted part of the development process.