Features overview

Defending against exploitation of unknown vulnerabilities

GrapheneOS is heavily focused on protecting users against attackers exploiting unknown (0 day) vulnerabilities. Patching vulnerabilities doesn't protect users before the vulnerability is known to the vendor and has a patch developed and shipped.

The vast majority of vulnerabilities are well understood classes of bugs and exploitation can be prevented by avoiding the bugs via languages/tooling or preventing exploitation with strong exploit mitigations. In many cases, vulnerability classes can be completely wiped out while in many others they can at least be made meaningfully harder to exploit. Android does a lot of work in this area and GrapheneOS has helped to advance this in Android and the Linux kernel. It takes an enormous amount of resources to develop fundamental fixes for these problems and there's often a high performance, memory or compatibility cost to deploying them. Mainstream operating systems usually don't prioritize security over other areas. GrapheneOS is willing to go further and we offer toggles for users to choose the compromises they prefer instead of forcing it on them. In the meantime, weaker less complete exploit mitigations can still provide meaningful barriers against attacks as long as they're developed with a clear threat model. GrapheneOS is heavily invested in many areas of developing these protections: developing/deploying memory safe languages / libraries, static/dynamic analysis tooling and many kinds of mitigations.

Unknown (0 day) vulnerabilities are much more widely used than most realize to exploit users not just in targeted attacks but in broad deployments. Project Zero maintains a spreadsheet tracking zero day exploitation detected in the wild. This is only a peek into what's happening since it only documents cases where the attackers were caught exploiting users, often because the attacks are not targeted but rather deployed on public websites, etc.

Remote code execution vulnerabilities are the most serious and allow an attacker to gain a foothold on device or even substantial control over it remotely. Local code execution vulnerabilities allow breaking out of a sandbox including the app sandbox or browser renderer sandbox after either compromising an app / browser renderer remotely, compromising an app's supply chain or getting the user to install a malicious app. Many other kinds of vulnerabilities exist but most of what we're protecting against falls into these 2 broad categories.

The vast majority of local and remote code execution vulnerabilities are memory corruption bugs caused by memory unsafe languages or rare low-level unsafe code in an otherwise memory safe language. Most of the remaining issues are caused by dynamic code execution/loading features. Our main focus is on preventing or raising the difficult of exploiting memory corruption bugs followed by restricting dynamic code execution both to make escalation from a memory corruption bug harder and to directly mitigate bugs caused by dynamic code loading/generation/execution such as a JIT compiler bug or a plugin loading vulnerability.

• Hardened app runtime
• Stronger app sandbox
• Hardened libc providing defenses against the most common classes of vulnerabilities (memory corruption)
• Our own hardened malloc (memory allocator) leveraging modern hardware capabilities to provide substantial defenses against the most common classes of vulnerabilities (heap memory corruption) along with reducing the lifetime of sensitive data in memory. The hardened_malloc README has extensive documentation on it. The hardened_malloc project is portable to other Linux-based operating systems and is being adopted by other security-focused operating systems like Whonix. Our allocator also heavily influenced the design of the next-generation musl malloc implementation which offers substantially better security than musl's previous malloc while still having minimal memory usage and code size.
  • Fully out-of-line metadata with protection from corruption, ruling out traditional allocator exploitation
  • Separate memory regions for metadata, large allocations and each slab allocation size class with high entropy random bases and no address space reuse between the different regions
  • Deterministic detection of any invalid free
  • Zero-on-free with detection of write-after-free via checking that memory is still zeroed before handing it out again
  • Delayed reuse of address space and memory allocations through the combination of deterministic and randomized quarantines to mitigate use-after-free vulnerabilities
  • Fine-grained randomization
  • Aggressive consistency checks
  • Memory protected guard regions around allocations larger than 16k with randomization of guard region sizes for 128k and above
  • Allocations smaller than 16k have guard regions around each of the slabs containing allocations (for example, 16 byte allocations are in 4096 byte slabs with 4096 byte guard regions before and after)
  • Random canaries with a leading zero are added to these smaller allocations to block C string overflows, absorb small overflows and detect linear overflows or other heap corruption when the canary value is checked (primarily on free)
• Hardened compiler toolchain
• Hardened kernel
  • Support for dynamically loaded kernel modules is disabled and the minimal set of modules for the device model are built into the kernel to substantially improve the granularity of Control Flow Integrity (CFI) and reduce attack surface.
  • 4-level page tables are enabled on arm64 to provide a much larger address space (48-bit instead of 39-bit) with significantly higher entropy Address Space Layout Randomization (33-bit instead of 24-bit).
  • Random canaries with a leading zero are added to the kernel heap (slub) to block C string overflows, absorb small overflows and detect linear overflows or other heap corruption when the canary value is checked (on free, copies to/from userspace, etc.).
  • Memory is wiped (zeroed) as soon as it's released in both the low-level kernel page allocator and higher level kernel heap allocator (slub). This substantially reduces the lifetime of sensitive data in memory, mitigates use-after-free vulnerabilities and makes most uninitialized data usage vulnerabilities harmless. Without our changes, memory that's released retains data indefinitely until the memory is handed out for other uses and gets partially or fully overwritten by new data.
  • Kernel stack allocations are zeroed to make most uninitialized data usage vulnerabilities harmless.
  • Assorted attack surface reduction through disabling features or setting up infrastructure to dynamically enable/disable them only as needed (perf, ptrace).
  • Assorted upstream hardening features are enabled, including many which we played a part in developing and landing upstream as part of our linux-hardened project (which we intend to revive as a more active project again).
• Prevention of dynamic native code execution in-memory or via the filesystem for the base OS without going via the package manager, etc.
• Filesystem access hardening

Sandboxed Google Play

GrapheneOS has a compatibility layer providing the option to install and use the official releases of Google Play in the standard app sandbox. Google Play receives absolutely no special access or privileges on GrapheneOS as opposed to bypassing the app sandbox and receiving a massive amount of highly privileged access. Instead, the compatibility layer teaches it how to work within the full app sandbox. It also isn't used as a backend for the OS services as it would be elsewhere since GrapheneOS doesn't use Google Play even when it's installed.

Since the Google Play apps are simply regular apps on GrapheneOS, you install them within a specific user or work profile and they're only available within that profile. Only apps within the same profile can use it and they need to explicitly choose to use it. It works the same way as any other app and has no special capabilities. As with any other app, it can't access data of other apps and requires explicit user consent to gain access to profile data or the standard permissions. Apps within the same profile can communicate with mutual consent and it's no different for sandboxed Google Play.

The core functionality and APIs are almost entirely supported already since GrapheneOS largely only has to coerce these apps into continuing to run without being able to use any of the usual invasive OS integration. A compatibility layer is also provided to support dynamically downloaded/loaded modules (dynamite modules). The compatibility layer will be gradually expanded and improved in order to get more of the Google Play functionality working.

GrapheneOS provides a dedicated compatibility layer for Play Store app installation/updates/removal teaching it to use the standard unprivileged approach available to sandboxed apps. It prompts the user to permit it as an app source and then prompts for the initial app install/update or removal. It will use Android 12's support for unattended updates when possible which means it can do unattended updates of modern (API 29+) apps where it was the installer for the currently installed version already.

See the usage guide section on sandboxed Google Play for instructions.

More complete patching

GrapheneOS includes fixes for many vulnerabilities not yet fixed in Android. On modern devices with Generic Kernel Image (GKI) support, we the update kernel to the latest stable GKI release many months before the stock OS gets the update. This means we're shipping hundreds of fixes not included in the stock OS including many security fixes. We also backport more fixes on top of this for the kernel and for other components too.

We often find new vulnerabilities ourselves and report them upstream. We've reported dozens of vulnerabilities for both the generic Android codebase and also for Pixels specifically. We also often find missed patches which were supposed to be included but were missed, especially when there are device specific components with partially shared but separate codebases for different devices.

Our overall approach is to focus on systemic privacy and security improvements but fixing individual vulnerabilities is still very important.

Disabling secondary user app installation

GrapheneOS adds a toggle to the user management settings for disabling secondary user app installation. You can install the apps you want to be usable in a secondary user and then disable the ability to install more apps as that user in the Owner profile. Android supports this as a standard device management feature but doesn't make it available to a user who owns their own device.

User installed apps can be disabled

GrapheneOS adds support for disabling user installed apps instead of only being able to disable system apps. This allows users to completely prevent one of the apps they've installed from being able to run without being forced to uninstall it and lose their app data. This is much stricter than the standard force stop feature which only prevents an app from starting itself and the app will start running again as soon as another app tries to open an activity or service it provides.

Broad carrier support without invasive carrier access

GrapheneOS has much broader carrier support than AOSP and mostly matches the stock OS on Pixels without making the same sacrifices. We convert their APN, carrier configuration, MMS and visual voicemail databases to the formats used by AOSP with our carriersettings project and other scripts. We strip out anti-user configuration requiring provisioning for tethering, forbidding disabling 2G, etc. We don't include the invasive carrier specific apps and support for Open Mobile Alliance Device Management (OMA DM) so we also strip out configuration depending on those.

See our usage guide section on carrier functionality for more details.

Private screenshots

GrapheneOS disables the inclusion of sensitive metadata in screenshots.

On Android, each screenshot includes an EXIF Software tag with detailed OS build/version information (android.os.Build.DISPLAY). It's the same value shown at Settings ➔ About device ➔ Build number. This leaks the OS, OS version and also usually the device family/model since builds are usually specific to a family of devices. GrapheneOS completely disables this tag.

On Android, each screenshot also includes EXIF tags with the local date, time and timezone offset. GrapheneOS disables this by default in order to avoid leaking the time and quasi-location information through metadata that isn't visible to the user. The date and time are already included in the file name of the screenshot which is fully visible to the user and can be easily modified by them without a third party tool. GrapheneOS includes a toggle for turning this metadata back on in Settings ➔ Privacy since some users may find it to be useful.