4 ms·

GrapheneOS primarily exists to greatly improve privacy and security compared to the Android Open Source Project (AOSP). AOSP provides far better privacy and sec

GrapheneOS primarily exists to greatly improve privacy and security compared to the Android Open Source Project (AOSP). AOSP provides far better privacy and security than a traditional desktop Linux distribution. It has a strong mandatory app sandbox, an increasingly good permission model moving more and more towards case-by-case consent, broad use of memory safe languages throughout the OS and app ecosystem, strong MAC/MLS policies developed as part of the whole OS, modern exploit protections, verified boot with downgrade protection for the whole OS and far more. GrapheneOS starts from the already good privacy and security of AOSP and greatly improves upon it. We greatly improve the permission model, exploit protections and much more but we depend on starting from a foundation that's already decent. Moving to a far less private and secure desktop software stack is going in the opposite direction from GrapheneOS. GrapheneOS doesn't exist to simply provide an alternative to mainstream operating systems but rather to offer much better privacy and security. We wouldn't be doing that if we were forking a desktop Linux environment and doing similar work for it. It would be nowhere close to the privacy and security of simply using an iPhone. That's a major part of why GrapheneOS is based on AOSP rather than it solely being about compatibility. Desktop distributions are incredibly far behind on privacy/security and lack any clear path to achieving the same things. Every year, Android makes backwards incompatible privacy and security improvements as part of a new target SDK version. Android retains compatibility with legacy apps, but apps distributed through the Play Store (and other app stores to an extent) are required to move to the new target API level within around a year. This results in apps being forced to conform to a gradually improving privacy and security model. There's no such thing for desktop Linux apps but rather apps choose how much they want to participate in nascent sandboxing efforts. GrapheneOS has near perfect compatibility apps from the Play Store via our sandboxed Google Play compatibility layer with the exception of banking and government apps. 90% of banking apps currently work on GrapheneOS because it greatly succeeds all of their security requirements and is only wrongly banned by a subset of those apps. These apps are gradually adding more anti-tampering and attestation checks for the hardware and OS, so maintaining compatibility has required us to gradually add more functionality working around it. We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it. A growing number of apps are choosing to stop banning using GrapheneOS due to pressure from our expanding userbase. Android is a large Linux operating system family. It's the mainstream form of Linux on personal computers. Android users are Linux users. For privacy and security, using a monolithic kernel written in C is definitely not a good thing. Doing much better than we are today partly requires moving away from so heavily depending on the Linux kernel for security. Android does a lot of Linux kernel hardening with attack surface reduction and exploit protections which are improved by GrapheneOS, but it's not enough. The massive torrent of severe vulnerabilities being discovered in the Linux kernel is going to get worse before it gets better and will remain a problem. Adopting hardware-based virtualization for isolation of apps and OS components including drivers is an important part of our roadmap.

tfrancisl 2mo ago
[flagged]
- grapheneos 2mo ago
  > I have read your marketing materials GrapheneOS is a non-profit open source project. We provide documentation and other information on the project. > Android is not a Linux distro nor is it directly derived from Linux Android is a family of Linux distributions. Linux is a kernel without a specific userspace and there are many different choices of libc, shell, init system, command-line utilities and far more. There are even more choices for the high level user interface. Android's userspace is largely specifically written to run on top of the Linux kernel with extensive use of SELinux and other Linux-specific APIs. A lot of the software you're considering to be Linux also runs on FreeBSD and elsewhere. FreeBSD is not Linux and the traditional desktop software stack largely shared with FreeBSD isn't Linux either. Android Open Source Project uses the upstream Linux LTS branches. The upcoming devices with GrapheneOS support from Motorola use latest Linux 6.18 LTS branch. We plan to port to newer Linux kernel branches throughout the lifetime of the devices. Google already does that for Pixels and it needs to start happening for other devices too. The upstream Linux LTS branches largely exist for Android with Google contributing a lot of the resources for it. Ubuntu and RHEL make their own LTS branches rather than using the ones from the Linux project. The lifetime for the upstream branches was increased from 2 to 6 years alongside Pixels increasing the support time to 5 years with the Pixel 6. It was decreased from 6 to 2 years because Pixels have been smoothly moving to newer kernel branches in production. It demonstrated the lack of need for the longer LTS branches not only for Android but more broadly. Pixels moved to 7 years of support with the Pixel 8 which wouldn't have been possible sticking to 1 kernel branch without a further lifetime increase. > Mobile phones are not "personal computers". Mobile phones are absolutely personal computers and should be treated as such. Many people use a mobile phone as their main personal computer. In large parts of the world, mobile phones are people's only personal computer. GrapheneOS can even be hooked up to a monitor, mouse, keyboard, game controller and other accessories. It has a very functional desktop mode. It can also run desktop Linux applications via the hardware accelerated virtualization support. It even has opt-in GPU acceleration via gfxstream. That's all standard functionality from the Android Open Source Project. > Trying to act like it being "mainstream" or "common" relative to desktop distros matters is just laughable. There are billions of Android users. Each of those users is a Linux user. Linux is the dominant OS family on personal computers due to Android. > And I take issue with the notion that a monolithic kernel cannot be secure. A monolithic kernel written in C with an extreme focus on performance at the cost of having immense complexity is not reasonably secure. Piling on better exploit protections is useful but has a limited impact and those protections don't work as well in the Linux kernel as they do in the much more security-oriented userspace. Everything in the kernel being in the same address space with no isolation for regular code is not a good setup for security and severely hinders the usefulness of many exploit protections. Further reducing attack surface even more than Android does is possible but is difficult while maintaining app compatibility. Hardware-based virtualization is the most realistic approach to dealing with the insecurity of the Linux kernel to properly protect it from userspace. Protecting drivers from exploitation largely involves moving most of the code to userspace which is the norm in the mobile world and should expand much further. Bluetooth, Wi-Fi and other code can be largely moved out of the kernel. Moving TCP/IP, filesystems and many other drivers out of the kernel is entirely possible. However, it starts to run up against the Linux kernel having a culture and approach strongly against doing it. The same thing has happened with the attempt to introduce Rust in the Linux kernel with immense resistance and obstruction to simply providing bindings to write non-core drivers in it. There's no current attempt to use Rust in the core kernel and it would be an immensely slow process even if that was happening. Hundreds of severe vulnerabilities being found per month with only a subset of those getting fixed is not a sustainable approach to making a reasonably secure OS. > then why arent you guys working on the next kernel for personal and high-performance computing We're doing initial work on expanding use of hardware-based virtualization to further reduce reliance on the Linux kernel for security. We're also building up our resources to be able to take on much bigger projects. Aside from that, we don't need to be doing things entirely on our own. A lot of what we want aligns with where AOSP is already headed and many others want the same things. AOSP added hardware-based virtualization with the userspace code written in Rust and a more secure approach to handling it in the kernel (pKVM) without our involvement. AOSP also began to make very limited use of this for OS sandboxing itself. We want to do much more with it and use it for sandboxing apps, which are not things Android is currently working on as far as we know but likely will be in the future.

tfrancisl 2mo ago

[flagged]

grapheneos 2mo ago
> I have read your marketing materials GrapheneOS is a non-profit open source project. We provide documentation and other information on the project. > Android is not a Linux distro nor is it directly derived from Linux Android is a family of Linux distributions. Linux is a kernel without a specific userspace and there are many different choices of libc, shell, init system, command-line utilities and far more. There are even more choices for the high level user interface. Android's userspace is largely specifically written to run on top of the Linux kernel with extensive use of SELinux and other Linux-specific APIs. A lot of the software you're considering to be Linux also runs on FreeBSD and elsewhere. FreeBSD is not Linux and the traditional desktop software stack largely shared with FreeBSD isn't Linux either. Android Open Source Project uses the upstream Linux LTS branches. The upcoming devices with GrapheneOS support from Motorola use latest Linux 6.18 LTS branch. We plan to port to newer Linux kernel branches throughout the lifetime of the devices. Google already does that for Pixels and it needs to start happening for other devices too. The upstream Linux LTS branches largely exist for Android with Google contributing a lot of the resources for it. Ubuntu and RHEL make their own LTS branches rather than using the ones from the Linux project. The lifetime for the upstream branches was increased from 2 to 6 years alongside Pixels increasing the support time to 5 years with the Pixel 6. It was decreased from 6 to 2 years because Pixels have been smoothly moving to newer kernel branches in production. It demonstrated the lack of need for the longer LTS branches not only for Android but more broadly. Pixels moved to 7 years of support with the Pixel 8 which wouldn't have been possible sticking to 1 kernel branch without a further lifetime increase. > Mobile phones are not "personal computers". Mobile phones are absolutely personal computers and should be treated as such. Many people use a mobile phone as their main personal computer. In large parts of the world, mobile phones are people's only personal computer. GrapheneOS can even be hooked up to a monitor, mouse, keyboard, game controller and other accessories. It has a very functional desktop mode. It can also run desktop Linux applications via the hardware accelerated virtualization support. It even has opt-in GPU acceleration via gfxstream. That's all standard functionality from the Android Open Source Project. > Trying to act like it being "mainstream" or "common" relative to desktop distros matters is just laughable. There are billions of Android users. Each of those users is a Linux user. Linux is the dominant OS family on personal computers due to Android. > And I take issue with the notion that a monolithic kernel cannot be secure. A monolithic kernel written in C with an extreme focus on performance at the cost of having immense complexity is not reasonably secure. Piling on better exploit protections is useful but has a limited impact and those protections don't work as well in the Linux kernel as they do in the much more security-oriented userspace. Everything in the kernel being in the same address space with no isolation for regular code is not a good setup for security and severely hinders the usefulness of many exploit protections. Further reducing attack surface even more than Android does is possible but is difficult while maintaining app compatibility. Hardware-based virtualization is the most realistic approach to dealing with the insecurity of the Linux kernel to properly protect it from userspace. Protecting drivers from exploitation largely involves moving most of the code to userspace which is the norm in the mobile world and should expand much further. Bluetooth, Wi-Fi and other code can be largely moved out of the kernel. Moving TCP/IP, filesystems and many other drivers out of the kernel is entirely possible. However, it starts to run up against the Linux kernel having a culture and approach strongly against doing it. The same thing has happened with the attempt to introduce Rust in the Linux kernel with immense resistance and obstruction to simply providing bindings to write non-core drivers in it. There's no current attempt to use Rust in the core kernel and it would be an immensely slow process even if that was happening. Hundreds of severe vulnerabilities being found per month with only a subset of those getting fixed is not a sustainable approach to making a reasonably secure OS. > then why arent you guys working on the next kernel for personal and high-performance computing We're doing initial work on expanding use of hardware-based virtualization to further reduce reliance on the Linux kernel for security. We're also building up our resources to be able to take on much bigger projects. Aside from that, we don't need to be doing things entirely on our own. A lot of what we want aligns with where AOSP is already headed and many others want the same things. AOSP added hardware-based virtualization with the userspace code written in Rust and a more secure approach to handling it in the kernel (pKVM) without our involvement. AOSP also began to make very limited use of this for OS sandboxing itself. We want to do much more with it and use it for sandboxing apps, which are not things Android is currently working on as far as we know but likely will be in the future.