{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibztsm6y47jlez35r6eetqrdi55au5hw3mz3bi5ilt2ndtu4oxvba",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mpacguwz6ll2"
  },
  "path": "/t/grapheneos-questions-that-surpass-the-project-itself/38790#post_5",
  "publishedAt": "2026-06-26T23:32:57.000Z",
  "site": "https://discuss.privacyguides.net",
  "textContent": "> 1- Given that GrapheneOS relies on the exact same Generic Kernel Image (GKI) branches as stock Android, how does the project fundamentally protect users against a zero-day vulnerability present in the upstream LTS kernel? It’s very well known that graphene has stricter policies like Selinux, but, if the kernel falls, its unlikely Selinux, Hardened Malloc will be able to catch anything since they are controlled by the kernel. How Graphene deal with this?\n\nGrapheneOS greatly improves the security of the Linux kernel by enabling more standard security features and adding our own. One of the biggest improvements is enabling hardware memory tagging for the kernel allocators which requires us to to fix bugs throughout the Linux kernel and Pixel kernel drivers. We develop and ship fixes for invalid memory accesses caught by hardware memory tagging similarly to how we do the same for userspace.\n\nGrapheneOS doesn’t use the same kernel branches as the stock Pixel OS. It uses the latest revisions of the much more up-to-date GKI LTS revisions. There’s always a large gap between the kernel version on the stock Pixel OS and GrapheneOS which grows larger the further away the stock Pixel OS currently is from one of the quarterly or yearly releases where they update the base kernel to a new one.\n\n> 2- How can GrapheneOS guarantee deep hardware security when the vendor modules (such as baseband and Wi-Fi drivers) interfacing with the 6.12 kernel remain closed-source and beyond the project’s ability to audit or patch?\n\nThere have never been any closed source kernel drivers in GrapheneOS. The kernel code is fully open source and nothing interferes with making changes to it. We regularly make changes to the Pixel kernel drivers to fix issues uncovered by hardware memory tagging.\n\n> 3- Because GrapheneOS must adhere to the Kernel Module Interface (KMI) to ensure hardware compatibility, doesn’t this strict ABI requirement prevent the implementation of more radical, structural kernel hardenings?\n\nGrapheneOS doesn’t follow the Kernel Module Interface ABI. It makes changes to the ABI including even enabling RANDSTRUCT on most devices which thoroughly changes the ABI. We don’t enable RANDSTRUCT on the Pixel 7a yet due to a Qualcomm Wi-Fi driver incompatibility we haven’t invested in figuring out. The core kernel and Pixel drivers just need to be built with the same RANDSTRUCT seed as part of one unified build which is straightforward.\n\nAndroid is moving to heavily using Rust in the kernel for Linux 6.12 and Pixels are moving to 6.12 with Android 17 QPR2. Rust in the Linux kernel isn’t compatible with RANDSTRUCT yet so we’re going to lose that in favor of using the Rust binder, ashmem and other drivers until it’s compatible. We do plan to continue using RANDSTRUCT again once it works with Rust.\n\n> 4-Does the focus on hardening the Android Open Source Project (AOSP) framework occasionally distract from the reality that modern exploits increasingly target deeply embedded SoCs and hypervisors instead of the OS itself?\n\nModern exploits are not increasingly targeting embedded SoCs or hypervisors. We’ve never seen an Android exploit targeting a hypervisor. There are examples of attacking the device via the GPU but we haven’t seen a real world case involving getting code execution on the GPU. There are attacks using remote exploits of radios which then need to exploit the OS via kernel or service exploits. We can defend against the OS being exploited from the radios and exploits of the radios will nearly always lose access after a power cycle of the radio.\n\nYou’re also not taking into account that we’re working with a major OEM and Qualcomm for upcoming devices with official GrapheneOS support.\n\n> 5-In a scenario where a kernel exploit relies on a logic bug rather than memory corruption, how do GrapheneOS’s specific compiler-level hardenings provide any meaningful defense?\n\nRemote exploits are nearly entirely one of two categories:\n\n  1. Memory corruption\n  2. Dynamic code loading via memory or storage\n\n\n\nGrapheneOS heavily defends against both categories. We have strong defenses against memory corruption. Dynamic code execution is nearly non-existent in GrapheneOS and blocked for nearly the entire base OS including but not limited to apps. We also provide toggles to block dynamic code loading for user installed apps. Dynamic native code execution is blocked in the kernel via SELinux so an app can’t do it even if they want to when it’s disabled. We also block class loading via the Android Runtime at a userspace level which is strictly for defending apps from their own mistakes. An app can still bundle an interpreter and run code with it or use interpreters from the OS such as the Unix shell.\n\n> 6- When users are led to believe GrapheneOS offers absolute privacy\n\nGrapheneOS has never led anyone to believe it offers absolute privacy but rather quite the opposite. We give tons of information on what it provides and how much still needs to be done to better protect privacy and securiy.\n\n> is there sufficient transparency regarding the fact that the hardware telemetry capabilities below the OS level (e Baseband/Mode/etc) remain out of the OS’s control\n\nCellular radios aren’t black boxes and can be researched. A lot of external research has been done into Qualcomm and Samsung cellular radios. The radios in GrapheneOS supported devices don’t have telemetry and don’t contact services on their own. Disabling cellular radio transmit/receive via airplane mode also does work properly on all of the devices we support including during early boot. Cellular radios are not implemented in a significantly different way from Wi-Fi, Bluetooth, GNSS, NFC or UWB in the supported devices. They’re not a privileged component and have similar isolation. It has been that way since before GrapheneOS started in 2014. The first devices we supported (Nexus 5 and Galaxy S4) had isolated cellular radios, although likely not isolated Wi-Fi or Bluetooth yet.",
  "title": "GrapheneOS questions that surpass the project itself"
}