KindnessInfinity

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.