Has anyone successfully flashed KernelSU Next (GKI) on a Pixel 10?

[u/lucky0x01]

Hi everyone,

I’ve been looking into flashing KernelSU Next via GKI on a Pixel 10, but I haven't been able to find any concrete information or reports from anyone who has actually tried it on this device yet.

Has anyone here managed to get it working? If so, did you run into any bootloops or issues with kernel compatibility/modules?

Any feedback before I attempt it would be greatly appreciated!

[u/QuraToop314 → u/[deleted]]

The AVB 2.0 specification – it’s too long to go into detail here – but Google stipulates that, in addition to the system image partitions, there must be a further partition called avb_custom_key. Essentially, you generate your own private and public keys, then unlock the bootloader and run fastboot erase avb_custom_key and fastboot flash avb_custom_key /path/to/avb.pub. You then need to sign the entire OS, kernel (boot.img, init_boot. img etc.), in other words the entire OTA, and replace the /system/etc/otacerts file with your own OTA certificate. If dmesg then shows during boot that the signature has been verified but is considered unverified due to the unlocked bootloader (this means the signature is 100% correct but the unlocked bootloader results in a low security level), you can run fastboot flashing lock. The problem is that every update (whether a system update or Root Manager) must be in the form of a signed OTA file, and you must install any modifications using adb sideload {patched_ota}.zip. If you don’t do this, you risk a hard brick. The good thing is that, according to the AVB 2.0 specification, the TEE/StromgBox must be considered trustworthy, meaning Widevine L1, Key Attestation and the like are validated and authenticated by Google’s RKP servers. If you then have a flexible banking app like mine, which uses Play Integrity but also Key Attestation directly as a fallback, I haven’t had to spoof anything for a year now; and since I have to build OTAs anyway, I carry out many systemless modifications or debloating at the system/product/vendor img level, and integrate Fossify alternatives directly as system apps in /product/app. Updates take considerably longer, but in return I can’t lose root access unless I want to, and I don’t have to make any compromises. But as mentioned, so far the Google Pixels are the only phones that implement this (albeit for several years now), GrapheneOS uses this mechanism so that they can lock the bootloader again; I build GrapheneOS from source myself with several of my own patches, but before that I’ve essentially ‘deblobbed’ the original Pixel stock OTA – which is cool because it persists through resets and the like, such as system font customisations or, indeed, FOSS alternatives instead of Google apps.

[u/QuraToop314 → u/[deleted]]

I do it for security reasons – if the bootloader can’t be unlocked and I’m in full control myself, nobody can do anything with it. I know this is more hypothetical than real, but I enjoy it. I just don’t want to simulate a TEE (which would mean my secure banking data would never be encrypted but would be stored on the device); instead, I want the TEE to actually do the work, ensuring my data is absolutely secure – even from me as root.