Back

By default, GrapheneOS blocks new USB connections when the device is locked in the Linux kernel and at a lower level via the USB-C and pogo pins controllers to defend the firmware and lower-level Linux kernel code too. Data is blocked in hardware once connections end.

https://grapheneos.org/features#usb-c-port-and-pogo-pins-control

If a user connected a malicious USB device while unlocked which tried to exploit this, general purpose exploit protections come into play. For the majority of the OS, our hardened_malloc project provides strong protections against heap corruption exploits. Kernel heap hardening is a separate thing.

One of the stronger defenses in hardened_malloc is our own implementation of hardware memory tagging (MTE) which integrated shortly after it shipped in production with the Pixel 8 (https://grapheneos.org/releases#2023103000) and we had it enabled by default in around a month (https://grapheneos.org/releases#2023110700).

Linux kernel has a standard disabled by default implementation of hardware memory tagging. We very recently began enabling to defend it from issues like this USB heap corruption vulnerability (https://grapheneos.org/releases#2025011500). It's a major improvement but still not nearly as good as hardened_malloc.

We also already had CVE-2024-53104 patched prior to this month since we ship the kernel.org LTS revisions long before the Android Open Source Project / stock Pixel OS. Our systemic defenses are far more important because they work before vulnerabilities are known, so we didn't lead with that fact.

Many people have the misconception that security is about patching vulnerabilities. That's the bare minimum. Security should to be part of the design and implementation from the beginning. Linux kernel is an example where that wasn't the case at all and it's hard to provide it.

Linux kernel is a large monolithic kernel, meaning it has no internal isolation. All of the code including obscure drivers enabled in the build have access to everything it does. It's almost entirely written in C, a memory unsafe language where many tiny mistakes are code execution vulnerabilities.

Linux kernel is currently a major weak point for Android's security. It's the easiest way out of both the app sandbox and the more constrained sandboxes used for Android media processing and Chromium renderer processes. The Linux kernel is also a major physical and remote attack vector itself.

@GrapheneOS Disagree strongly with this. Android's use of outdated, maliciously misemgineered access control mechanisms ("NSA Linux") instead of the good ones Linux offers is the weak point. Android is an utterly garbage OS you managed to make respectably less garbage, on top of a kernel with lots of good and bad points, but that's strong if you use it right.

@dalias Access control is primarily for securing userspace rather than the kernel itself. SELinux offers a large amount of capabilities for securing userspace which aren't available through other access control mechanisms. Linux doesn't have any modern object capability system and there would still be a need for static, declarative policies if it did. Android also heavily uses SELinux for kernel attack surface reduction too. There isn't any serious alternative upstream. It's the only option.

@dalias Linux kernel maintainers have both accepted and rejected dozens of little access control features for providing inflexible versions of what can be done through writing declarative SELinux policies.

Access control is a very small part of defending the kernel itself against attacks. The main issue with the kernel is that it's a massive monolith with no sandboxing for drivers, filesystems, etc. and increasingly immense complexity for core kernel components for max scalability, etc.

@dalias Linux chose performance over security and correctness from the start. It continues choosing performance and scalability over security and correctness today. It's a massive mess. The userspace APIs and access control aren't really a big part of what we consider wrong with it. POSIX permissions, ACLs, etc. and layering on a bunch of hard-wired special cased policies and complex MAC/MLS are a terrible approach compared to a more modern system but it's not really a huge problem.

@dalias There's nothing we can do to change how much of a disaster it is in terms of the kernel being exploited to escape sandboxes or as the main attack vector to exploit the device. We have hardware memory tagging for the kernel enabled now and we can work on adding deterministic guarantees similar to hardened_malloc and other allocator hardening but it's still going to be disaster. We also have to do something about GPU drivers doing insane things with memory which bypass this hardening.

@dalias A vulnerability in a GPU or Wi-Fi driver shouldn't compromise the security of the whole OS because it should be isolated. Filesystems should at least be possible to run isolated. Linux is fundamentally opposed to that design. Still feasible to coerce it into working that way by running separate Linux kernels isolated from each other side-by-side. It will add a bunch of overhead vs. it being designed that way to start.

They also have problematic attitudes towards undefined behavior, etc.

@lispi314 @dalias We mean that it would be possible to run an isolated Linux kernel to run the Linux kernel ext4, f2fs or exFAT driver, another for a Linux kernel Wi-Fi driver, another for a GPU driver, etc. and turn it into a swarm of Linux kernels acting as a poor man's microkernel. It would be far higher overhead than an actual microkernel but it's a possible approach, at least as a higher security mode. Running groups of applications in virtual machines would be a separate thing from that.