Hi Everyone,
I’m working on a custom i.MX8M Plus board running Yocto Kirkstone and U-Boot 2022.04, with Secure Boot enabled via HABv4.
As part of our security hardening, I backported the CVE-2023-39902 patch (https://github.com/u-boot/u-boot/commit/99286cb3a4d3c0bcbb88ae313f3d872f34d3ffbc) from U-Boot 2023.07 to our U-Boot 2022.04 tree. This patch enables FIT image verification in SPL by computing a SHA256 hash of the u-boot.itb and storing it at the end of the u-boot-spl-ddr.bin binary.
I have verified via hexdump that the hash is correctly embedded in both the u-boot-spl-ddr.bin and the final flash image. However, during boot on actual hardware, the contents of fit_hash appear to be overwritten in RAM before they can be used for verification. As a result, the SPL FIT hash comparison fails, breaking Secure Boot.
IVT and CSF are appended after the hash in the final image layout.
No part of the signing process (hab-bootloader-sign.inc) overwrites the hash.
Printed memory addresses and values of fit_hash via SPL debug logs, and they confirm the overwrite happens after reset/init during early boot.
Is there a known issue or RAM region conflict in U-Boot 2022.04 SPL for i.MX8M when reserving extra sections like .fit_hash?
Are there any restrictions on where in RAM the hash can be safely placed during SPL execution?
How does U-Boot 2023.07 ensure this section is preserved during early SPL stages?
Can NXP recommend a safe memory location or method for storing this hash in SPL that avoids interference from other structures (e.g. CSF, IVT, or relocated code)?
If anyone from NXP or the community has experience applying this patch to older U-Boot versions or has guidance on memory layout adjustments in SPL, your help would be greatly appreciated.
Thanks in advance!
—
Arpan