zlacker

>>moelf+(OP)
I was bit confused why this was notable, but the Pixel 9a just released Thursday. So this is an incredibly fast turnaround for a community OS.

>>Jeremy+N3
Anyone know why drivers in this OS can't be ported to Linux, so it could support newer phones as well?

>>mixmas+F8
Android Open Source Project and operating systems based on it like GrapheneOS are Linux distributions. The kernel drivers are Linux kernel drivers. The userspace drivers are part of Android's Treble hardware abstraction layer providing forwards compatibility with future Android releases and SELinux-based sandboxing with the drivers split up into isolated processes. Most of the driver complexity is in userspace with most kernel drivers acting as shims between the isolated drivers and the hardware. It's done that way for practical reasons on Android but it's good for security.

Treble's compatibility system isn't very relevant to us right now. There's a new Android release every month: a monthly, quarterly or yearly release. The devices we currently support (Pixels) receive each of these updates officially. Most Android devices do not get the monthly or quarterly updates, only the yearly ones. Other devices rely on partial backports of security patches (Android Security Bulletins) to an initial release, which are provided for ~3-4 years after the initial yearly release. If we supported typical Android devices with that situation, then we'd at least partially rely on Treble to provide the latest OS version. Pixels are currently the only devices meeting our hardware security requirements listed at https://grapheneos.org/faq#future-devices. Having proper updates for 7 years from launch is just part of that, most of the requirements are for hardware-based security features like the secure element features, hardware memory tagging, pointer authentication, USB controller support for blocking new connections and disabling USB data, etc.

GrapheneOS uses the 6.1 and 6.6 long term support branches of the Linux kernel with 6.12 as the next one that's likely going to be used to replace 6.6 for on-device virtual machines and the emulator with Android 16.

>>strcat+pa
Sounds like Android is making a microkernel out of Linux.

>>speed_+Hb
There are some huge drivers from companies like Broadcom and Qualcomm. There's still a massive amount of kernel driver code along with the massive amount of core kernel code. Android is the main driving force behind the push for Rust for Linux kernel drivers because Google wants all these SoC and device drivers to start being written in Rust for security reasons but also for stability too. Driver memory corruption bugs are a huge source of both security and stability issues. A majority of new code in Android releases since Android 13 has been in memory safe languages. The Linux kernel is increasingly the elephant in the room with the monolithic kernel driver (zero isolation / sandboxing within the kernel) combined with memory unsafety. It's largely the opposite of Android's extensive work to improve security in userspace. They've worked hard on getting exploit mitigations into the kernel but those tend to be much weaker than they are in a lot of userspace (browser renderer processes have similar issues).