[OnePlus 3T Guides, News, & Discussion] smaeul:
Step-by-step instructions for reproducing this work will be in the second post.

Regardless of anyone's opinion about it being a good idea, some people prefer to run their device with a locked bootloader, whether for security, to avoid the 5-second wait on boot, or for some other reason. Unfortunately, it seems to be common knowledge around these forums that you cannot re-lock your bootloader on this device after installing a custom firmware or recovery, or at least you will "brick" your device by trying. After being re-locked, the bootloader appears to load your custom boot.img/recovery.img, fail to verify it (or crash in the process), and immediately reboot. So consensus is that everyone is stuck with the 5-second warning screen.

However, the blog post releasing the bootloader vulnerabilities shows proof (see the image halfway down the page) that at least one person was able to flash a modified boot image and still be able to boot with a locked bootloader. Taking advantage of the vulnerabilities in the OOS 4.0.1 bootloader described on that page, I did some research into why he was able to boot (albeit still with a warning) while everyone else gets stuck in a loop. I'll skip the process of experimentation, and go straight to the results.

The bootloader for this device is provided by Qualcomm/CAF (see https://github.com/OnePlusOSS/android/blob/bd6a70d6218dbc0e72f70740422e3dac2fdc82fb/default.xml#L32). Source is at https://source.codeaurora.org/quic/la/kernel/lk/tree/?h=LA.HB.1.3.1.c1.

The bootloader has two states, locked and unlocked. (If you read the slides linked below, you'll see that some Android bootloaders, such as Intel's, have a third "verified" state; ours does not). In the unlocked state, no verification of the boot image is performed at all, so the presence of a signature is not important. In the locked state, the bootloader expects a signature to be present just past the end of the boot image (calculated based on the lengths in the header), following the scheme described in this LWN article. Additional documentation from Qualcomm is here.

If the signature is valid, the device boots the kernel without warning.

If the signature is invalid (does not match the kernel or is not signed by the appropriate key), the device boots with a verification warning like the one seen here.

If the signature is missing (currently the case on all custom kernels and recoveries), the device immediately reboots.

When built from source, the signature is added by the boot_signer utility in system/extras/verity. This utility gets called from build/core/Makefile when PRODUCT_SUPPORTS_BOOT_SIGNER is set for the device. Normally this is enabled from build/target/product/verity.mk when dm-verity is enabled for the device, like it is on the stock firmware. However, since custom ROMs disable dm-verity, they end up disabling boot.img signing as well.

Thus, the purpose of this thread is to encourage custom ROM, kernel, and recovery developers to enable boot.img signing in their device tree, or to manually run boot_signer on their generated boot.img files, or even simply concatenate a valid (that is, parseable by the bootloader, while not cryptographically correct) signature to the end of the file. Note that for AnyKernel-like packages that run mkbootimg on the device, this will have to be done afterward. Even if developers do not start adding signatures to kernels they release, it should be possible to create a flashable zip that fake-signs any installed custom kernel, that way you can keep your bootloader locked without waiting for an update.

While this step will prevent bricking devices by locking the bootloader, a worthy goal in itself, it does not remove all boot delays/warnings. This should be possible by generating and flashing your own signing key to the keystore partition with fastboot, as described in the linked slides. I have not had a chance yet to try this. However, the current bootloader (as of OOS 4.0.3) is vulnerable to the bug fixed here. This means that if the size of the boot.img does not match the size reported in the signature, the bootloader does not attempt to verify it cryptographically and simply returns success. This allows custom kernels/recoveries to boot without any warning or prompt at all. This is how I have my device working right now.

Unfortunately, this is likely a very bad idea going forward. The device appears to use a different flash storage encryption key based on what security state the bootloader is in. This explains problems where people "without encryption" get prompted for a password after first installing TWRP, and threads such as this one. Once the bug is fixed, the bootloader will be in a red state (invalid signature) or at least a yellow state (non-OEM key) and will likely use the "untrusted" key, forcing everyone who uses this trick to wipe their data after updating the bootloader.

Documentation:

Android Verified Boot: https://source.android.com/security/verifiedboot/verified-boot.html

Android Keystore: https://developer.android.com/studio/publish/app-signing.html

Android Verified Boot: https://lwn.net/Articles/638627/

Qualcomm Bootloader: https://developer.qualcomm.com/download/db410c/little-kernel-boot-loader-overview.pdf