Auditor

requirements required to be Android, so it can't be referred to as Android, but rather it's an OS with Android app compatibility. It preserves what's actually needed for compatibility in practice, while not being strictly bound by those requirements. The intentional deviations from these are documented, and there are a bunch of them. > Lastly, I wonder how this will do over time considering Fuschia. If it ends up shipping as a replacement for the core OS, with Android running in a virtual machine or on top of a compatibility layer like gVisor, that would just mean that there's a better base to build on than before. All of the work done by the project would still be relevant in a future like that. I'm not so sure that's truly going to happen though.

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

tical approach is using virtualization to reinforce the app sandbox and user profiles. Eventually, the virtual machines can drop having their own Linux kernels (see gVisor as an example of this). In the very long term, the Linux kernel at the core of the OS could eventually go away too. I'd recommend checking out the standalone projects like https://github.com/GrapheneOS/hardened_malloc and https://github.com/GrapheneOS/Auditor for an idea of what the project is focused on doing. The hardened_malloc implementation supports other operating systems, as does Auditor, which supports verifying the stock OS on many mobile devices (they need to be added one-by-one to the internal database based on users submitting attestation samples with the app) and CalyxOS in addition to GrapheneOS. The OS project itself is still in the early stage of reviving it, porting over past work and getting the basics done. It's very focused on the infrastructure and low-level work right now. Working on the higher level features that are more user facing and bundling various apps, etc. is not a priority right now. It doesn't even bundle F-Droid right now, because it's not quite at the point where bundling any third party apps makes sense. It also needs to be determined how to best approach that. A lot of these things will also be done in collaboration with other projects like CalyxOS, with GrapheneOS focusing more on low-level security hardening. CalyxOS is primarily working on areas like the backup service implementation and various other higher-level services, and a lot of this will be used by GrapheneOS too.

ing all of the infrastructure and preventing it from ever pushing out another update to the existing installs. The OS was never compromised, but it lost all of the infrastructure and resources supporting it so it has taken a long time to even get some basics back up and running. Most of the initial focus after the disaster was on standalone projects like https://github.com/GrapheneOS/hardened_malloc and https://github.com/GrapheneOS/Auditor. It took a long time to get things back up and running, and it has definitely been massively set back both not only in terms of the development work but also in many other ways. It has still managed to continue onwards and while the OS itself hasn't been fully restored, there's a bunch of useful standalone work that's far better than anything the project offered in the past. You're substantially misrepresenting the events that occurred based on a very incomplete account of the events that you've seen. People seeing your comment are going to end up with an incorrect understanding, just as you did. You're stating your assumptions and misconceptions about what happened as if they're facts. It's a very incorrect account of a very small part of the story. This game of broken telephone where people misinform themselves and then propagate variations of that to many other people is a poor way of spreading knowledge.