GrapheneOS [Unofficial]

Our site's chat room information now provides Discord and Matrix as the 2 options:

https://grapheneos.org/contact#community

We're not listing Telegram because it's a much worse experience than Discord.

IRC is available but too limited especially with most people using Matrix and Discord now.

We added https://grapheneos.org/discord as a redirect to a permanent Discord invite link to make it easy to remember and share.

For Matrix, joining #community:grapheneos.org provides a list of all our non-archived rooms. 2 main rooms are regrowing after recently being bricked.

The software we use for bridging our chat rooms across platforms recently added support for Telegram's topics feature. We've merged our Telegram groups into a unified https://t.me/GrapheneOS group. It improves the user experience on Telegram but Discord still works much better.

There's a bug in the fwupd service that's causing the fastboot claim interface failure for our web installer and also similar failures for CLI fastboot:

https://github.com/fwupd/fwupd/issues/6437

You can work around this by stopping fwupd such as with systemctl stop fwupd.service.

This issue has unfortunately stopped MANY Linux users from successfully installing GrapheneOS. They've had to run the web installer on Windows, macOS or a Linux distribution without this issue such as ChromeOS or Android. Users on an OS like Arch Linux will often have added it.

There was also a similar bug in GVFS which appears to be resolved now. Many distributions freeze their packages for months or even years with only security bugs with a CVE assignment getting patched. These bugs have hindered adoption of GrapheneOS. It's hard to know how much.

Pixel 8 providing hardware memory tagging support is a massive security advance for GrapheneOS. This hardware feature only helps if the OS uses it like GrapheneOS, and the security it provides entirely depends on how it's used. We have a great implementation in hardened_malloc.

GrapheneOS on the Pixel 8 and Pixel 8 Pro is the first platform with this feature. At the moment, we enable it for most of the base OS. We fixed some issues with the Chromium PartitionAlloc implementation with the latest release of Vanadium so it can now work for Vanadium too.

In the upcoming release of GrapheneOS, we've added a toggle for force enabling memory tagging for every user installed app along with a per-app toggle in case you run into an app where it doesn't work. If you enable this, you'll have memory tagging for nearly everything!

GrapheneOS already provided substantially better exploit protections than the stock Pixel OS. Difference between GrapheneOS with and without memory tagging is comparable. It's such a huge advancement we've made the rare decision to consider this new feature mandatory right away.

Alongside the new per-app and global default memory tagging toggles for user installed apps, we've also replaced the global native debugging toggle with a similar system. Many users who disabled this ran into some banking apps, games, etc. using this for weak anti-tampering.

We've also added notifications for when apps are killed due to a memory tagging violation or trying to use native debugging (ptrace).

We don't provide a toggle for memory tagging with the base OS since it works well and any issue that's found should be fixed or worked around.

If users choose to use memory tagging for user installed apps not marked as being compatible by the developers, it will be up to users to choose if they want to disable. We recommend not disabling it unless it causes frequent crashes and considering using a different app instead.

If apps bundle standalone executables run separately from their app processes, those won't have memory tagging yet unless the app developers build them with it enabled. Examples are apps running Tor as an executable. WireGuard doesn't matter since the executable made in Go not C.

Chromium barely uses the system allocator. It marks itself compatible with memory tagging but disables it by default. Latest release of Vanadium enables memory tagging, and we're going to improving it. This creates a much larger security gap between Vanadium and other browsers.

Most apps use the WebView library to handle web content. On GrapheneOS, the WebView library is Vanadium and memory tagging works for it. Some browser apps use the WebView rather than forking Chromium, so they get memory tagging protection but lack per-site sandboxing right now.

Browsers based on Chromium like Brave and Chrome need to enable memory tagging themselves. They also don't enable strict site sandboxing or CFI yet.

Browsers based on Firefox lack a content sandbox on Android, not just site isolation. They're also missing CFI and memory tagging.

Desktop Firefox has a content sandbox, but it's much weaker than the Chromium sandbox and lacks a complete implementation of site isolation. They use a fork of Chromium sandbox on Windows but in a lower security mode. On Android, they haven't enabled any form of sandboxing yet.

Changes in version 119.0.6045.163.2:

• enable enforcing memory tagging for all processes when available
• fix upstream bug in memory tagging implementation by not trying to re-enable it since it breaks in apps with memory tagging disabled

A full list of changes from the previous release (version 119.0.6045.163.1) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Changes in version 84:

• update max supported version of Play services to 23.45
• update max supported version of Play Store to 38.4

A full list of changes from the previous release (version 83) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

Due to our Matrix rooms getting bricked yet again by Matrix state resolution bugs, we've decided to add Discord as a more robust and widely accessible option:

https://discord.gg/GE6r8YYrnM

Our Matrix, IRC, Telegram and Discord rooms are bridged together but we were focused on Matrix.

IRC rooms on libera.chat:

#grapheneos #grapheneos-offtopic #grapheneos-testing #grapheneos-dev #grapheneos-media #grapheneos-infra #grapheneos-releases

Telegram:

https://t.me/GrapheneOS https://t.me/GrapheneOS_Offtopic https://t.me/GrapheneOS_Testing

Could add other rooms on TG.

The new Matrix rooms replacing the rooms bricked by the state resolution bugs yet again are #general:grapheneos.org (main room) and #offtopic:grapheneos.org. It will take a long time for people to move over and some people will switch to IRC, Discord, etc.

Pixel 4, Pixel 4 XL and Pixel 4a are end-of-life and shouldn't be used anymore due to lack of most security patches for firmware and drivers. We're currently supporting them via a legacy Android 13 branch separate from these mainline GrapheneOS releases. We're considering porting them to Android 14 to continue providing extended support longer than initially planned to keep them as a way to preview the current version of the OS.

Tags:

• 2023111500 (Pixel 4a (5G), Pixel 5, Pixel 5a, Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, emulator, generic, other targets)
• 2023111500-shusky (Pixel 8, Pixel 8 Pro)

Changes since the 2023110700 release:

• Sandboxed Google Play compatibility layer: replace cross-user intent broadcasts with user-local ones to avoid occasional background service crashes
• fix upstream bug causing crash for previewing live wallpapers
• kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Generic 5.10): update to latest GKI LTS branch revision
• Seedvault: update to latest revision (will be replaced with a better backup implementation in the future)
• Vanadium: update to version 119.0.6045.134.0
• Vanadium: update to version 119.0.6045.163.0
• Vanadium: update to version 119.0.6045.163.1
• GmsCompatConfig: update to version 83
• Camera: update to version 64
• Auditor: update to version 77

Changes in version 119.0.6045.163.1:

• fix handling of the ACTION_WEB_SEARCH intent added by GrapheneOS which regressed from upstream changes
• restore standard WebView client hint behavior to avoid potential compatibility problems and because it can't improve privacy there yet due to the user agent not being minimized in the same way as the browser so it only adds a way to fingerprint it (we plan to provide a toggle for minimized WebView user agent and client hints)

A full list of changes from the previous release (version 119.0.6045.163.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Changes in version 119.0.6045.163.0:

• update to Chromium 119.0.6045.163
• disable high entropy client hints

A full list of changes from the previous release (version 119.0.6045.134.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

Notable changes in version 64:

• add support for hardware camera capture and zoom buttons
• improve video recording user experience when audio permission isn't granted, which isn't needed with include audio disabled
• improve error handling for video recording by distinguishing between errors where the video is still saved and errors preventing it from being usable
• fix error message for reporting broken camera showing wrong camera (front/rear reversed)
• update SDK to 34 (Android 14)
• update target API level to 34 (Android 14)
• update Android build tools to 34.0.0
• update Material Components library to 1.10.0
• update CameraX library to 1.4.0-alpha02
• update zxing library to 3.5.2
• update Gradle to 8.4
• update Android Gradle plugin to 8.1.1
• update Kotlin to 1.9.20
• update NDK version to 26.1.10909125 instead of using the older default set by the Android Gradle plugin
• improve code quality

A full list of changes from the previous release (version 63) is available through the Git commit log between the releases.

This app is available through the Play Store with the app.grapheneos.camera.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them.

Releases of the app signed by GrapheneOS with the app.grapheneos.camera app id are published in the GrapheneOS app repository and on GitHub. You can use the GrapheneOS app repository client on Android 12 or later for automatic updates.

Releases are initially pushed out through the Beta channel for both the Play Store and our app repository and then get moved to the Stable channel.

GrapheneOS users must obtain GrapheneOS app updates through our app repository since fs-verity metadata is now required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

Notable changes in version 77:

• update CameraX library to 1.3.0
• update Gradle to 8.4
• update Kotlin to 1.9.20
• update NDK version to 26.1.10909125 instead of using the older default set by the Android Gradle plugin

A full list of changes from the previous release (version 76) is available through the Git commit log between the releases.

The Auditor app uses hardware security features on supported devices to validate the integrity of the operating system from another Android device. It will verify that the device is running the stock operating system with the bootloader locked and that no tampering with the operating system has occurred. It will also detect downgrades to a previous version.

It cannot be bypassed by modifying or tampering with the operating system (OS) because it receives signed device information from the device's Trusted Execution Environment (TEE) or Hardware Security Module (HSM) including the verified boot state, operating system variant and operating system version. The verification is much more meaningful after the initial pairing as the app primarily relies on Trust On First Use via pinning. It also verifies the identity of the device after the initial verification. Trust is chained through the verified OS to the app to bootstrap software checks with results displayed in a separate section.

This app is available through the Play Store with the app.attestation.auditor.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them.

Releases of the app signed by GrapheneOS with the app.attestation.auditor app id are published in the GrapheneOS app repository and on GitHub. These releases are also bundled as part of GrapheneOS. You can use the GrapheneOS app repository client on Android 12 or later for automatic updates.

Releases are initially pushed out through the Alpha channel channel for both the Play Store and our app repository, then get moved to the Beta channel and finally the Stable channel

GrapheneOS users must either obtain GrapheneOS app updates through our app repository or install it with adb install-multiple with both the APK and fs-verity metadata since fs-verity metadata is now required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

Changes in version 82:

• update max supported version of Play services to 23.44
• update max supported version of Play Store to 38.3

A full list of changes from the previous release (version 82) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

We've added an updated list of hardware requirements:

https://grapheneos.org/faq#future-devices

GrapheneOS on the Pixel 8 is the first platform using ARM MTE in production and it's such a massive improvement for exploit protection that it has to be considered a hard requirement going forward.

Changes in version 119.0.6045.134.0:

• update to Chromium 119.0.6045.134

A full list of changes from the previous release (version 119.0.6045.66.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

This release has been in the Stable channel for a while now, making GrapheneOS the first platform deploying hardware memory tagging to users in production. We've made further progress since this release towards enabling Chromium's MTE support in Vanadium.

https://grapheneos.social/deck/@GrapheneOS/111369970010555326

https://grapheneos.social/@GrapheneOS/111369816784502180

Our latest release has hardware memory tagging (MTE) support for hardened_malloc enabled by default for 8th generation Pixels which added support for it.

We also want to enable Clang's stack allocation MTE and Chromium's MTE support for Vanadium soon.

hardened_malloc sets random memory tags for each slab allocation which includes everything 128k and below. This provides probabilistic memory safety for the heap. It also excludes certain tags to provide multiple deterministic guarantees preventing classes of memory corruption.

hardened_malloc excludes default zero tag, a reserved free tag, current or previous (if free) tag of neighboring allocations and previous tag used for the last allocation in the same slot. Excluding neighboring tags means small and linear underflows/overflows are always detected.

Use-after-free is always detected until a new allocation with same random tag is made in the same slot. hardened_malloc has a per-size-class slab allocation quarantine with 2 parts (randomized and first-in-first-out) to delay reuse of the slot at the cost of wasting some memory.

Since previous tag is also excluded in addition to the reserved free tag, use-after-free is guaranteed to be detected for a cycle through both quarantines, an additional allocation cycle and then another round through both quarantines before there's a chance the same tag is used.

GrapheneOS ships kernel updates much faster than stock Pixel OS. For devices using 5.10 LTS branch, we're on latest 5.10.199 revision compared to the stock OS being on 5.10.157. This can be a hassle due to regressions we need to solve, but it recently saved us a lot of trouble.

Android 14 released with a major f2fs data corruption bug caused by LTS kernel backporting shenanigans. This was already resolved in the kernel shipped by GrapheneOS in our experimental Android 14 release on October 6th/7th (we ported in around 2 days after it was published).

In addition to fixing a backport, November release of AOSP and stock Pixel OS include a few robustness improvements to hold up better against future f2fs data corruption bugs or hardware issues causing data corruption. f2fs recently incorporated those improvements upstream too.

Pixel 4, Pixel 4 XL and Pixel 4a are end-of-life and shouldn't be used anymore due to lack of most security patches for firmware and drivers. We're considering porting them to Android 14 to continue providing extended support longer than initially planned to keep them as a way to preview the current version of the OS despite them not being secure. It will be a significant effort to port them properly without lost functionality and we're looking for a new developer to fund rather than reassigning any developers from their existing work on the OS.

Tags:

• 2023110700 (Pixel 4a (5G), Pixel 5, Pixel 5a, Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, emulator, generic, other targets)
• 2023110700-shusky (Pixel 8, Pixel 8 Pro)

Changes since the 2023103100 release:

• full 2023-11-01 security patch level
• full 2023-11-05 security patch level for generic targets and 5th/8th generation Pixels (6th/7th generation Pixels are marked as 2023-11-01 upstream which may be due to a missing Mali GPU kernel patch we can work on obtaining to apply early)
• rebased onto UP1A.231105.003 (generic) and UD1A.231105.004 (shusky) Android Open Source Project releases
• Pixel 8, Pixel 8 Pro: always enable hardware memory tagging (there is no longer an opt-in toggle) which is currently used everywhere other than Vanadium (coming soon), vendor executables and user installed apps with their own native code not marked as compatible with memory tagging
• disable GWP-ASan since it's a bug finding feature rather than a hardening feature and doesn't preserve all the hardened_malloc security properties for the random allocations in random system processes where it gets activated especially now that memory tagging is supported
• Launcher: add missing catch for null pointer exception (upstream bug) triggered by Signal
• revert change to show crash dialog for first crash of an app since boot since this results in a high support burden from the many third party app crashes it uncovers especially since it's not enabled on the stock OS
• always compile VPN service packages with speed filter to avoid background recompilation since many of these apps only automatically connect at boot and the user has to manually reconnect if the OS restarts them such as when users manually trigger app restart via the background recompilation notification
• kernel (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Generic 5.10): update to latest GKI LTS branch revision including update to 5.10.199
• backport health permission UI fixes from AOSP
• backport DocumentsUI (Files) fix from AOSP preventing bypassing restrictions via initial open directory
• GmsCompatConfig: update to version 81
• GmsCompatConfig: update to version 82
• use sdk_phone_x86_64 (emulator) target as the default one for convenience
• flash-all: raise minimum fastboot version to 34.0.4

Pixel 5 is receiving official support past the end of the official update guarantee which is what we predicted for the Pixel 4a (5G) and Pixel 5. It would make a lot of sense for them to be supported until the Pixel 5a end-of-life but it's unclear if that's what will happen.

Nexus and Pixel devices have often received longer support than the minimum guarantee. Pixel C was released December 2015 with a 3 minimum guarantee and got updates until June 2019. Many people misinterpret the minimum guarantee as the end-of-life date, which is not how it works.

Pixel 8 has moved to a 7 year minimum guarantee for major OS updates and security updates, and we don't expect them to go past that. However, we do expect that the Pixel 6 and Pixel 7 will keep getting official major OS updates for their whole 5 year security update guarantee.

In the near future, we plan to ship support for a per-app toggle for memory tagging, a per-app toggle for ptrace replacing the global one, duress PIN/password and a toggle for enabling Android Auto by granting a list of special privileges which can be reduced via shims over time.

We're also working on various other small features and initial work on some longer term projects including App Communication Scopes. In order to work on more at the same time, we need more developers, and we're currently moving forward with hiring additional full time developers.

This is a preview of App Communication Scopes from an incomplete proof of concept we made for a previous version. The goal is to provide the ability to disable communication with user installed apps within a profile with the ability to enable it on a case-by-case basis instead.

GrapheneOS already provides Contact Scopes and Storage Scopes as alternatives to granting apps contacts and media/storage permissions where apps will work without access to any of the user's data and the user grants it case-by-case. We plan to provide more features like these.

Our upcoming release has hardware memory tagging enabled unconditionally on devices supporting it to replace the opt-in we added in security settings. This will likely be released at the end of the day tomorrow.

See https://grapheneos.social/@GrapheneOS/111338677911401250 on our implementation.

Our approach enables memory tagging for nearly all of the base OS, user installed apps opting into memory tagging support and user installed apps not bundling any native libraries. For other user installed apps, we'll be adding a per-app memory tagging toggle in a future release.

Our authoritative DNS nameservers now support DNS-over-TLS (DoT) with authentication via DANE TLSA and/or WebPKI. This allows DNS resolvers to make queries via securely encrypted connections. We're already seeing lots of DoT encrypted connections from multiple DNS providers.

Using DNS-over-TLS for authoritative DNS is bleeding edge and not widely supported yet. Cloudflare and most ISPs don't support this yet. Vast majority of the DNS-over-TLS connections are coming from Google Public DNS. There are only a small number of connections from elsewhere.

We're currently implementing this with an nginx TLS to TCP reverse proxy in front of PowerDNS.

https://github.com/GrapheneOS/infrastructure/commit/38bb002a019a0947c1b2c1bd0e7f5b602ae85f5c https://github.com/GrapheneOS/ns1.grapheneos.org/commit/387f1027f8904fc148217a697fdad66d089c6cfc

This is a very forward-looking improvement. Google is the only major provider using it and only for opportunistic encryption right now.

Changes in version 82:

• avoid crash in KidsSettingsModule initializer which tries to use a privileged operation (previous fix was incomplate)

A full list of changes from the previous release (version 81) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GrapheneOS now has hardware memory tagging support in our Stable channel. Memory tagging greatly improves protection against targeted attacks. Thanks to hardware support on the Pixel 8 and Pixel 8 Pro, it's extremely low overhead despite the massive benefits it's able to provide.

GrapheneOS users on the Pixel 8 and Pixel 8 Pro can enable memory tagging via Settings ➔ Security ➔ More security settings ➔ Advanced memory protection beta on supported devices. We'll be enabling it by default soon since we have a solid approach to preserve app compatibility.

We integrated it into hardened_malloc where it's able to provide stronger security properties than the experimental stock OS implementation.

Our current toggle enables it for everything other than Vanadium, vendor executables and user installed apps bundling native libraries.

We'll be enabling memory tagging support for Vanadium by default via the standard Chromium implementation.

For the near future, we'll be leaving memory tagging disabled by default for user installed apps bundling native libraries to avoid introducing a new compatibility issues.

It will be possible to enable memory tagging for all user installed apps with the ability to opt-out for specific apps where it causes issues. We want to eventually have it globally enabled by default, but we expect it to uncover a lot of issues hardened_malloc hasn't before.

It's also possible to use MTE for protecting from stack buffer overflows and use-after-scope by aligning and tagging variables with an escaping pointer. LLVM has an implementation of this and we've confirmed it works but it may not be optimized enough to enable it quite yet.

When fully integrated into the compiler and each heap allocator, MTE enforces a form of memory safety. It detects memory corruption as it happens. 4 bit tags limit it to probabilistic detection for the general case, but deterministic guarantees are possible via reserving tags.

In hardened_malloc, we deterministically prevent sequential overflows by excluding adjacent tags. We exclude a tag reserved for free tag and the previous tag used for the previous allocation in the slot to help with use-after-free detection alongside FIFO and random quarantines.

MTE support for protecting the Linux kernel isn't enabled yet, but we can likely enable that by default too. However, it's currently part of kasan and is more oriented towards debugging than hardening. It's not entirely clear that enabling it in the current state is a good idea.

Changes in version 81:

• avoid crash in KidsSettingsModule initializer which tries to use a privileged operation
• update max supported version of Play services to 23.43
• update max supported version of Play Store to 38.2

A full list of changes from the previous release (version 80) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.