GrapheneOS

GrapheneOS, 20 days ago

We've had around 2.5 years to evaluate impact of Generic Kernel Images. Our conclusion is that this caused more harm than good to GrapheneOS.

Generic Kernel Images are supposed to make kernel updates easier via a stable ABI, but Pixels update all drivers for GKI updates anyway.

GrapheneOS, 20 days ago

The stability of the ABI isn't perfect and many changes get reverted due to breaking the ABI. It also leads to even the GKI LTS branch with the latest merges of LTS releases to lag behind, particularly recently. We attribute some of that to the resources wasted on their CNA work.

GrapheneOS, 20 days ago (edited 20 days ago)

CVE system did not work for the Linux kernel either way, but it's certainly not fixed through making nearly every backport into a CVE and ignoring anything not backported. We don't particularly care about it but rather our concern is wasting scarce resources on something useless.

GrapheneOS, 20 days ago

Barely any resources are dedicated to stable Linux kernel releases. There's very little testing and review. There have been multiple filesystem corruption bugs backported to ext4 and f2fs recently. Some didn't exist in mainline but rather are from missing interdependent changes.

GrapheneOS, 20 days ago

GKI LTS branch reverting a bunch of commits changing the ABI, working around the changed ABI in other cases and lagging behind is making it harder for us to deal with these issues. It'd be smoother upgrading the kernel and fixing API/ABI conflicts. ABI isn't fully stable anyway.

GrapheneOS, 20 days ago

Android reached the point where mainline kernels were usable beyond needing out-of-tree drivers for hardware and the Tensor Pixel drivers are way less invasive and easier to port to new releases. GKI has made a mess of it, and it doesn't even make it easier for Pixels but harder.

GrapheneOS, 20 days ago

5.10 kernel drivers for Pixel 6 were ported to 5.15, 6.1 and 6.6. They simply haven't decided to move to a newer branch yet. The kernel for Pixel 8 doesn't bother having a device kernel tree anyway but rather uses generic sources for GKI and all the drivers, so what's the point?

GrapheneOS, 21 days ago

@blenderdumbass 125.0.6422.72 is the Chromium release number. Only the final .0 at the end is added by Vanadium.

GrapheneOS, 21 days ago

@sandboxgeneral We accidentally broke your reply by reposting the message.

GrapheneOS, 21 days ago

@sandboxgeneral Yes, you can use dual SIM with eSIM and physical SIM across every device. Dual eSIM support is also one of the features but we'd need to check which devices support it in practice and it's not as heavily tested. All the devices support having 2 eSIMs alongside a physical SIM but not all support dual SIM with both being eSIM like they do with eSIM/physical.

GrapheneOS, 21 days ago

We made our own wipe-without-reboot but we're backporting the Android 15 implementation instead of using ours. They made it in response to our vulnerability report about this (CVE-2024-29748):

https://grapheneos.social/@GrapheneOS/112204428984003954

Pixels added a firmware mitigation against it in April too.

GrapheneOS, 21 days ago

The April release added 2 Pixel specific protections against the 2 vulnerabilities we reported, but both vulnerabilities essentially impact all Android devices and were only addressed for Pixels. The factory reset interruption also isn't fully addressed until they ship this part.

GrapheneOS, 21 days ago

@evilcookies98 @puppygirlhornypost In some ways, GrapheneOS is more stable than the stock OS. It has significantly more bug fixes applied at any given time and we hardly have any bugs introduced by our features in practice. We do uncover a lot of bugs in the OS and apps with hardening features, such as that Bluetooth LE audio bug which broke some people's Bluetooth LE audio devices, but not widespread enough that it was caught before Alpha. It also came close to getting into the Stable channel.

GrapheneOS, 21 days ago

@evilcookies98 @puppygirlhornypost We uncovered that bug via our hardened_malloc project which detects and prevents exploitation of many memory corruption bugs. It was easy for us to fix due to the hardware memory tagging feature we use that's exclusive to 8th generation Pixels and the biggest current reason of many we only support Pixels right now. It broke on the older Pixels too due to zero-on-free but would have been a lot harder to fix it instead of disabling zero-on-free for that process.

GrapheneOS, 21 days ago

@evilcookies98 @puppygirlhornypost Users run into an app with a memory corruption bug and learn about the per-app exploit protection compatibility mode toggle, and then they can deal with it going forward. It would ideally not happen but it's outside our control since we can't force everyone else to test their C and C++ code with ASan/HWASan/MTE to avoid shipping memory corruption bugs occurring during regular use of their apps.

GrapheneOS, 21 days ago

@evilcookies98 @puppygirlhornypost We started making an app compatibility database to handle compatibility mode automatically for very common apps but we don't have the spare resources to do much with that yet. Pixel Camera is widely used by our users and shipped a memory corruption bug occurring in regular use a few months back so we added it to that database and people didn't have to do it themselves. We don't currently bother if it's not very widely used.

GrapheneOS, 21 days ago

@evilcookies98 @puppygirlhornypost You can use Pixel Camera on GrapheneOS and that feature would probably be available as long as you had sandboxed Google Play and Google's Speech Recognition & Synthesis app too.

GrapheneOS, 21 days ago

@evilcookies98 @puppygirlhornypost It's also possible to use the full Google TalkBack instead of our fork of the open source TalkBack. Their full one has a few extra features like OCR.

A minor thing that's missing is OCR of text in the recent apps screen without an accessibility service since it's not part of AOSP.

It's a bit nasty Google has made a fair bit of bleeding edge accessibility closed source and often Pixel specific. Overall, it's mostly only Google service stuff that's not open.

GrapheneOS, 21 days ago

@evilcookies98 @puppygirlhornypost FIDO2 and passkey support is the main other thing that's strangely a proprietary, closed source part of Play services. It all works via sandboxed Google Play, etc. and there's nothing stopping there being other implementations but it's still annoying they would put such a useful security feature into Play services instead of an AOSP mainline module. Their justification is they did it to backport it to ancient Android versions, but they could have done both.