GrapheneOS has experimental support for the Pixel 4 and 4 XL in the development branch, but it needs testing and lots of work to complete it. It's important to fully support these to be able to support the upcoming Pixel 4a and other current generation Qualcomm SoC devices too.
Conversation
Wi-Fi doesn't work yet since we disable dynamic kernel modules and the driver needs compatibility fixes for building it into the kernel even though it's supposed to be supported. Separately from that, some userspace fixes appear to be required for it. Probably not the only issue.
1
11
Supporting these reference devices enables much more easily porting to other devices and advances the project by supporting the latest and greatest SoC platform and hardware-based security features. Supporting the initial devices for a generation is always going to be hardest.
1
7
Linux kernel drivers often have initialization issues when built into the kernel. They often initialize themselves as soon as possible instead of waiting until it's actually needed. That can cause them to try loading firmware or running userspace helpers before it's possible.
1
5
Disabling dynamic modules substantially improves the granularity of CFI, since otherwise the compiler assumes non-static functions can be called indirectly. This ends up uncovering more issues like this one where only assembly uses a function indirectly:
1
5
Also likely that we'll find new issues with hardened_malloc. AOSP and Qualcomm have improved code quality and testing over the years but we still find memory corruption bugs during regular use or running the standard test suite. Better than other SoC platforms but still a mess.
1
8
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Replying to
There's the massive and quite comprehensive CTS (Compatibility Test Suite) which runs unprivileged tests primarily from the perspective of apps and to some extent via adb shell. CTS-on-GSI runs the CTS from a generic AOSP system image. VTS (Vendor Test Suite) tests the HALs.
1
1
Android has a stable ABI for the HALs provided by the SoC implementation. VTS is a privileged test suite heavily stressing that API. There's information on it here including documentation on fuzzing: source.android.com/compatibility/. Not sure how much the vendors make use of ASan/KASan.
1
2
CTS is not particularly good at testing lower level portions of the OS because it's meant to be run on a production user build and the app context it runs from is a very strict sandbox with very little access. Uses adb shell for some of it but that preserves the security model.
On a production build, you can't really use adb shell to do much debugging of the OS, only apps. It can get a bit more via the device management API. CTS can mark the vast majority of apps it installs as debuggable (other than testing the security checks for debugging features).
1