final [GrapheneOS] ๐Ÿ“ฑ๐Ÿ‘๏ธโ€๐Ÿ—จ๏ธ's avatar
final [GrapheneOS] ๐Ÿ“ฑ๐Ÿ‘๏ธโ€๐Ÿ—จ๏ธ
npub1c9d9...sqfm
Keeping the fight. Community Moderator for #GrapheneOS https://discuss.grapheneos.org/u/final This is a personal account. I do not speak on behalf of GrapheneOS developers as a whole (nor am I) and suggestions shall not be endorsements.
#GrapheneOS version 2024032100 released: This is a larger update containing a lot of fixes for apps or apps using libraries that are breaking with Android 14 QPR2. The temporary Bluetooth compatibility toggles have also been removed as Bluetooth devices should be fixed. See the changes: - Bluetooth: revert broken upstream change and changes depending on it to fix Galaxy Watch 6 Classic and likely other devices impacted by the same issue (this was a failure of upstream testing and release engineering for AOSP and doesn't impact the stock Pixel OS because it uses a different APEX module revision branched from an older revision of AOSP but it will impact every other AOSP-based OS on Android 14 QPR2 since there isn't a Bluetooth mainline module published in the Play Store and AOSP yet) - Android Runtime: disable stripping symbols for libart to restore compatibility with many obfuscated Chinese apps using a specific obfuscation SDK which was broken by Android 14 QPR2 when not using the mainline ART module due to the mainline module being based on an older codebase - Android Runtime: remove Android's hard-wired speed-profile compilation for launcher apps which was limiting ahead-of-time compilation for user installed launcher apps to the parts of the code included in baseline and/or cloud profiles rather than compiling the whole app via our default speed compilation which we use to replace JIT compilation and JIT profiles guiding background AOT compilation - backport 12 upstream fixes from the mainline MediaProvider, Wifi, NetworkStack and HealthFitness APEX modules - allowlist using device controls quick tile when unlocked since it already has a toggle for controlling availability so our new default requirement of the device being unlocked needs to be overridden for it - revert disabling hardened_malloc for Broadcom Bluetooth HAL (does not appear to be a memory corruption bug found by GrapheneOS but rather the stock OS is using an older Bluetooth module without the issue) - revert allowing users to disable Bluetooth for Bluetooth system app (does not appear to be a memory corruption bug found by GrapheneOS but rather the stock OS is using an older Bluetooth module without the issue) - more complete setup design configuration to improve appearance of Setup Wizard, etc. - Settings: fix upstream footer formatting issue for App pinning screen - update timezone module to Android mainline 341510010 (based on tzdata 2024a) - kernel (5.15, 6.1): improve support for hosting servers by enabling SYN cookies as we do for the older kernels - kernel (6.1): drop obsolete usage of YAMA which we replaced with our dynamic SELinux flag extension - kernel (5.10): update to latest GKI LTS branch revision - GmsCompatConfig: update to version 99
#GrapheneOS: Our users have found additional Android 14 QPR2 Bluetooth memory corruption bugs which so far appear to be specific to pairing recent Galaxy Watch devices with GrapheneOS. We're working on finding and fixing this as we did with the BLE audio bugs. The Android 14 QPR2 Bluetooth LE audio bugs we found were fixed in the March 9th release of GrapheneOS: We also reported it as an #Android vulnerability in the same day and it has been initially triaged by them as a High severity and High quality report. Users on the stock OS are experiencing Bluetooth regressions with Android 14 QPR2 too. These latent and often exploitable bugs breaking functionality for certain users in certain situations often get turned into reliable crashes/breakage due to our memory corruption protections. The downside is that more of our users get impacted by the issues and they tend to break a specific niche feature completely such as whatever is being used by the Galaxy Watch. On the stock OS, it breaks for some users and may break in a subtle way such as corrupting other data. The upside is our users are protected against exploitation through these bugs and many others. Since the issues stop being subtle and turn into reliable breakage, it also forces us to look into what's wrong and we often figure out how to fix it completely as we did for BLE audio. The end result is that GrapheneOS users end up with an OS that's not just more secure but has additional bug fixes since our exploit protections force us to fix these issues right after they're introduced instead of remaining dormant breaking things for some users for months. #security #privacy
#GrapheneOS version 2024031100 released: This fixes several small regressions causes by the transition over to Android 14 QPR2 while defaulting our new USB-C port control feature and additional integration of ARMv9 security features. See the changes: - toggle USB port after device unlock to automatically detect a device plugged in while it was in charging-only mode while locked, etc. - Tensor Pixels: change default mode for our USB-C port control feature able to truly disable USB at a hardware level to "Charging-only when locked, except before first unlock" (doesn't apply to connections that were made before locking or first unlock) which can be changed by users in Settings > Security > USB-C port - fix Wi-Fi auto-turn-off issues leading to it not triggering in certain cases caused by backwards incompatible changes in Android 14 QPR2 - Pixel 8, Pixel 8 Pro: fix enabling DisplayPort alternate mode support - Pixel 8, Pixel 8 Pro: fully enable PAC and BTI for userspace too, especially since ShadowCallStack is not currently used in userspace and Clang type-based CFI is only used for a large subset of the important userspace code - GmsCompatConfig: update to version 98 - improve internal infrastructure used by GrapheneOS features #security #privacy
#GrapheneOS: We're continuing work on integrating ARMv9 security features. MTE is the highest impact and most interesting of these features, but there's less important work to do expanding usage of PAC and BTI. Android uses Clang's type-based CFI but not everywhere so BTI is still useful. Pixel 8 was the first device with a usable MTE implementation despite it launching as part of ARMv8.5. Android world stayed on ARMv8.2 until ARMv9 and Apple hasn't shipped MTE. Apple was a much earlier adopter of the much less useful PAC. From our perspective, PAC was a misstep. PAC is a weak probabilistic mitigation requiring lots of case-by-case integration. MTE can provide many deterministic guarantees and does a much better job as a probabilistic mitigation by catching memory corruption rather than only protecting specific memory corruption targets. PAC requires bits which would have been better served by 16-bit MTE support and using a 48-bit address space. Hardware shadow stack is a better backwards edge CFI approach. MTE could be used to mimic hardware shadow stack support via a reserved tag for ShadowCallStack. We're currently the first platform using userspace heap MTE for hardening in production. We plan to do the same with userspace stack MTE along with doing both in the kernel. Turning ShadowCallStack in the kernel into a hardware protected shadow stack would also be nice to ship. In the kernel, Pixel OS uses PAC for backwards edge CFI and Clang type-based CFI for forward-edge. We use ShadowCallStack + PAC together and enable BTI in addition to type-based CFI due to lots of functions being excluded from type-based CFI. We plan to do the same in userspace.
General #Android tip which also works in #GrapheneOS: You can split screen apps. I don't see people do it a lot but it's pretty awesome. Go to your recent apps menu and tap the icon above the screenshot of the app from where it is left off and select "Split screen". The first choice goes at the top, so pick the one you want at the top first! You can adjust the width of the apps too. image
#GrapheneOS has discovered a use-after-free memory corruption bug in Android 14 QPR2 for Bluetooth LE. This issue impacts the stock operating system as well. We have reported this to Google as a security bug today. We have already made an initial, minimally invasive patch to fix this: We have noted elsewhere that this code needs a major refactor and shouldn't be using raw pointers, but we want to avoid introducing new bugs with a quick patch. The hardware memory tagging support for Pixel 8 and later has helped massively. On devices earlier than them it likely would manifest as BLE audio devices not working without an error message since it wouldn't crash. Our MTE implementation detects it which is what led to us being able to fix it so quickly. The hardening GrapheneOS implements doesn't just help the users by making them safe from exploits, it helps developers by helping them to create more secure software by catching memory corruption bugs and uncovering them thanks to our features. See: Pixels shipped a humongous hardware security feature by having memory tagging support but they do not use it for the OS to save around ~3.25% of memory usage. GrapheneOS enabled it by default for the OS and known user-installed apps compatible with it. As we have mentioned before, GrapheneOS is the first platform using MTE in production and Vanadium is the first web browser too. Progress towards Android 14 QPR2 is coming along nicely and hopefully all (which are minimal) regressions will be fixed soon.
โ†‘