Android Keymaster Issue on Qualcomm Devices

On modern Qualcomm-based Android devices, inserting a secondary bootloader between the primary bootloader and the Android boot.img can cause Android to hang at the boot logo. When this happens, logcat typically shows the following error during Keymaster initialization:

E KeyMasterHalDevice: resp->status: -38
F [email protected]: Configure failed

Root Cause

This issue stems from a mismatch between the OS version and security patch level metadata passed during boot and what the Android system expects.

On Qualcomm devices, this metadata is passed to the Keymaster Trusted Application (TA) in the Trusted Execution Environment (TEE) by the primary bootloader. Once set, this metadata is software fused in milestone, and cannot be changed for the remainder of that boot cycle.

If a secondary bootloader is inserted between the primary bootloader and the Android boot.img, the primary bootloader will read and use the metadata from the secondary bootloader instead of the metadata in the actual Android boot image. This mismatch causes the Keymaster initialization to fail.

This version binding behavior was introduced with Keymaster TA 2.0 and newer, as seen in lk2nd boot_verifier implementation.

Workaround

The only reliable way to work around this issue is to ensure that the metadata passed to the keymaster TA by the bootloader chain matches the Android system.

When using a secondary bootloader, you must build it with OS version and patch level metadata that matches the Android system image it boots. This way, when the primary bootloader reads metadata from the secondary bootloader, it will be consistent with the Android boot.img.

If you're building the secondary bootloader with mkbootimg, use the --os_version and --os_patch_level flags. For example:

mkbootimg \
  --kernel u-boot.gz.dtb \
  --os_version 15.0.0 \
  --os_patch_level 2025-05-00 \
  -o u-boot-2nd.img

These values must exactly match what the Android system expects to prevent Keymaster initialization failure.

This workaround will only work on unlocked devices, as unlocking disables the boot signature verification process, leaving only the version binding issue.

References

This category currently contains no pages or media.