@lw64 @mntmn

ok here's how the chain of trust works on Qualcomm SoCs in Android phones

So qualcomm socs can hold multiple public key hashes, typically this is for Qualcomms signing key, and for the OEMs. These are literally burnt into the silicon at the factory

some early parts of the boot process that are secure are only signed by Qualcomm and vendors can't modify this code (exactly which pieces this is has changed over the years, in 2018 it was only secure world/trustzone but new socs also have the hypervisor locked down). Other parts of the bootloader like the UEFI implementation and ABL (Android bootloader EFI app) are only signed by the vendor, they can modify them as they place.

these key hashes never change, and can't be changed (... mostly).

there is no "updating the keys"

The Android boot image (Linux kernel/initramfs/dtb etc) are all hashed and that hash is signed also by the vendor (all parts here are vendor signed now), all this is stored in the "vbmeta" partition. The boot partition(s) are hashed and checked against this every boot. This is the Android Verified Boot (AVB) process.

When you "unlock the bootloader" all you're doing is disabling the verification of data against the hashes in the vbmeta partition, it's totally skipped.

In theory you can enroll a custom Android Verified Boot key (AVB key), this is stored in the RPMB (look it up but basically it's some special magic write-once rollback protected storage in the MMC/UFS) and allows you to flash your own boot image and own vbmeta signed with your own key, you may then "re-lock" the bootloader, and now you have Android secure boot with your own key.

For mainline purposes this would allow us to re-lock a bootloader where U-Boot is in the boot image, and U-Boot could have EFI secureboot public keys embedded in it, allowing for EFI secureboot!

However, this is all designed with the expectation that you are running software delivered to you like a custom Android ROM. If you the user want to modify the kernel you can't, because you don't have the keys.

the only way to maintain user freedom is to have the user possess their own private keys. Maybe this is doable with some really good tooling, but you also need the user to definitely back up their keys during provisioning and have methods for them to unlock the bootloader again (oh also you need to disable bootloader unlocking after re-locking which is vendor/device specific in most cases, yay)

ok let's forget about the android stuff, when it comes to the earlier parts of the boot chain i hope it's clear that even if you buy unfused devices and intend to blow the fuses yourself, we don't have access to the software needed to do this, and if we did, expecting users to do it themselves would be absurd and require they're able to store the keys. If we do it (e.g. like SHIFT decided to enable vendor secureboot on the new shiftphone 8) it means that their users can't modify the bootloader.

fundamentally the hardware and firmware on these SoCs is not designed for this usecase.

If we wanna treat it like x86 where you jsut enroll your own keys, we can at least do that but it's way more janky and non-standard.