Thread by @GrapheneOS

@GrassFedBitcoin @CalyxOS GrapheneOS is heavily focused on security enhancements making exploitation significantly harder:

grapheneos.org/features

Those other operating systems don't improve resistance against exploitation and won't provide more resistance against an exploit working against AOSP/stock.

@GrassFedBitcoin @CalyxOS The vast majority of remote code execution exploits are based on memory corruption bugs. Defending against those is a major focus of GrapheneOS. A lot of the bugs won't be exploitable beyond denial of service. In most cases, the exploits will need substantial changes at minimum.

@GrassFedBitcoin @CalyxOS If they specifically target GrapheneOS and put work into adjusting their exploit chains and finding new bugs as necessary, then they could certainly develop an exploit working against GrapheneOS. Costs will be higher and they'll usually need to specifically take it into account.

@GrassFedBitcoin @CalyxOS Firmware exposed to remote attack surface like the radios (Wi-Fi, Bluetooth, cellular, NFC) and GPU is generally a lot harder to exploit than the OS and those components are isolated. It's much rarer and generally involves using an OS exploit to bypass the component isolation.

@GrassFedBitcoin @CalyxOS Nearly all of these exploits are memory corruption bugs. GrapheneOS does actually provide hardening for firmware through attack surface reduction including the LTE only mode and other features. It can't directly harden firmware, but it can avoid exposing as much attack surface.

@GrassFedBitcoin @CalyxOS So, for example, with the GrapheneOS 4G only mode enabled, vulnerabilities in 2G, 3G and 5G are not usable to exploit the cellular radio, only those exposed by 4G.

The radio firmware also does have substantial hardening and internal sandboxing, but GrapheneOS can't improve it.

@GrassFedBitcoin @CalyxOS GrapheneOS also fortifies the OS against exploitation by an attacker that has gained code execution on a component like the GPU or radio.

Main hardening we provide is for the most common path of exploiting an RCE bug in userspace and then exploiting the kernel to escape sandbox.