Imx8mp secure boot "verification failed for NULL hash node" in FIT image conf entry

Technical Support
, ,
1

I’m running into an issue with secure boot setup on the 8mp where the main OS image fails to boot, and I’m not sure how to resolve the issue.

I’ve successfully followed the various readmes and documents to both use CST to generate a set of signing keys for u-boot, as well as the FIT image and conf signing keys. The yocto build succeeds without complaining.

I’ve deployed u-boot to the board successfully - and this all seems to work as expected - I can see it behaving like a build with signing enabled. The device is not yet fused or closed, so any errors are informational (though hab_status also reports no events).

The issue arises when trying to boot the main device OS - it’s finding the partition but FIT signatures are failing (some text lightly edited to hide sensitive info):

Scanning mmc 2:1...
Found U-Boot script /boot.scr
970 bytes read in 1 ms (947.3 KiB/s)
## Executing script at 50280000
13367 bytes read in 2 ms (6.4 MiB/s)
## NOTE: Bootloader seems to support secure boot.
14 bytes read in 3 ms (3.9 KiB/s)
29440972 bytes read in 92 ms (305.2 MiB/s)
## Loading kernel from FIT Image at 50300000 ...
   Using 'conf-freescale_imx8mp-verdin-customized.dtb' configuration
   Verifying Hash Integrity ... sha256,rsa2048:fit-image-1-  error!
Verification failed for '<NULL>' hash node in 'conf-freescale_imx8mp-verdin-customized.dtb' config node
Failed to verify required signature 'key-fit-conf-1'
Bad Data Hash
ERROR -2: can't get kernel image!

Inspecting the yocto built FDT image with dumpimage shows that indeed, the “hash” node for the FDT conf entires is all “unavailable” - though clearly it has been signed successfully given the presence of an actual signature:

  Timestamp:    Thu Jan  1 00:00:00 1970
 Configuration 1 (conf-freescale_imx8mp-verdin-customized.dtb)
  Description:  0 Linux kernel, FDT blob
  Kernel:       kernel-1
  FDT:          fdt-freescale_imx8mp-verdin-customized.dtb
  Hash algo:    sha256
  Hash value:   unavailable
  Sign algo:    sha256,rsa2048:fit-conf-1
  Sign padding: pkcs-1.5
  Sign value:   [hexadecimal signature]

I suppose it makes sense a configuration doesn’t have a hash value since it’s not a physical “blob” of data, just references to other data blobs - but I don’t know where to begin troubleshooting the u-boot failure in that it’s looking for a hash that doesn’t (cannot?) exist.

The yocto build is based off the 7.7.0 release tag in the manifest.

Thanks!
~BW908

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

To help you properly, could you specify which exact version of Torizon OS or BSP you are running? You mentioned the 7.7.0 release tag, but I’d like to confirm the specific image version and whether you’re using Torizon OS or a BSP reference image. You can get this information using the tdx-info command on your device. More details are available at tdx-info documentation.(1)(2)

That said, based on your description, the error message “Verification failed for ‘’ hash node” suggests that U-Boot is unable to properly verify the FIT image configuration signature. This can happen when there’s a mismatch in how the FIT image was signed versus how U-Boot is attempting to verify it.(2)(3)

Key Areas to Check

1. FIT Image Signing Configuration

The FIT image signing is controlled by several variables. According to the documentation, when using the tdx-signed or torizon-signed class, the following default configuration applies:(2)

  • UBOOT_SIGN_ENABLE = 1 (enables FIT signing)
  • UBOOT_SIGN_KEYDIR = ${TOPDIR}/keys/fit (location of RSA keys)
  • UBOOT_SIGN_KEYNAME = dev (key name for configuration nodes)
  • UBOOT_SIGN_IMG_KEYNAME = dev2 (key name for individual images)

Verify that your conf/local.conf has the appropriate class inherited:(2)

INHERIT += "tdx-signed"

2. U-Boot Hardening and Bootm Protection

The Verdin iMX8M Plus has U-Boot hardening enabled by default when Secure Boot is active. This includes protection against execution of unsigned software by the bootm command. The hardening ensures that only signed FIT images with proper configuration signatures can boot.(3)

The error you’re seeing suggests U-Boot is enforcing signature verification but cannot find or validate the configuration hash. This could indicate:(2)(3)

  • The public key embedded in U-Boot doesn’t match the private key used to sign the FIT image
  • The FIT image configuration signature format doesn’t match what U-Boot expects
  • There’s a mismatch in the signing algorithm or key names

3. Verify Key Consistency

Ensure that:

  1. The keys in ${TOPDIR}/keys/fit/ were properly generated
  2. U-Boot was built with the correct public keys embedded
  3. The FIT image was signed with the corresponding private keys
  4. The key names (UBOOT_SIGN_KEYNAME and UBOOT_SIGN_IMG_KEYNAME) are consistent between U-Boot build and FIT image generation

4. Check Device Tree Control FDT

The U-Boot hardening features use a control Device Tree to configure secure boot behavior. Make sure your U-Boot build includes the proper control DTB with the signing key information.(3)

Troubleshooting Steps

  1. Verify the FIT image structure: Use dumpimage -l <fit-image> to inspect all nodes and their signatures
  2. Check U-Boot key embedding: Verify that U-Boot has the public keys properly embedded during build
  3. Review build logs: Look for any warnings during the FIT image signing process in your Yocto build logs
  4. Test with a fresh key set: Try regenerating all keys and rebuilding both U-Boot and the FIT image from scratch

Once you provide the specific OS version, I can give you more targeted guidance based on the exact configuration for that release.

Best regards,
Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Greetings @bw908,

This looks like a similar issue that was just reported recently elsewhere. It seems to be some form of dependency chain issue.

Let me ask, the keys for the FIT image signing in your build. How are they generated? Do you create the keys yourself prior to the build and then configure the build to use your keys? Or, are you letting the build auto-generate keys itself?

I believe if you’re letting the keys be auto-generated, the issue is that sometimes the keys don’t actually auto-generate correctly. Which results in your FIT image not properly being signed.

Could you confirm these details, just to see if the issue is similar to the other case we’ve seen.

Best Regards,
Jeremias

4

Hi Jeremias,

You are correct, I set FIT_GENERATE_KEYS to 1 to have them auto-generated. I do see data in the .crt and .key files in the specified directory.

Does leaving this set to 1 cause the keys to be regenerated each build? that doesn’t seem to be the case based on the file timestamps, but based in your description it could explain it - I recall reading somewhere that the build process doesn’t properly handle a change in the signing keys and needs a forced clean/rebuild to bust the cache.

I did also find a reference to the exact same issue on the NXP forums but alas no solution there either. (https://community.nxp.com/t5/i-MX-Processors/iMX8-U-Boot-FIT-Image-Signature/m-p/1429547)

Is the fix to manually generate the RSA-2048 keypairs with the correct names and rebuild?

Thanks!

~BW908

5

Does leaving this set to 1 cause the keys to be regenerated each build?

The description of the variable seems to suggest that it should only generate the keys if they are missing.

Is the fix to manually generate the RSA-2048 keypairs with the correct names and rebuild?

I’m not certain if it will. It depends if the issue is on the generation of the keys, or the actual signing. It’s worth a try though.

I know in the other reported case auto-generated keys were being used. In that case the user accidentally deleted their keys directory after the first build to do a rebuild. Normally this wouldn’t matter because a new set of keys should be regenerated and used on rebuild. But, in this case new keys weren’t being generated at all.

If I remember correctly, I think a completely clean build worked. Which would suggest some stale/incorrect cache data was being used previously.

Best Regards,
Jeremias

7

Thanks - I did already try a clean rebuild and forcing a u-boot and kernel recompile (which should invalidate all downstream cache and cause a rebuild)

It’s confusing because I can clearly see all the components have been signed in the FIT image since there are signature fields throughout, but the error message (perhaps unhelpfully or misphrased) is complaining about the absence of hash on the conf nodes for it to verify. The nodes that have actual binary content (dtbs, kernel, initramfs) do have hash values populated.

I did try running the yocto build directly but it fails with

Could not find configuration node
ERROR -2: can't get kernel image!

which is potentially expected as the stock image is incomplete; we add several customizations using TCB (and I believe I’ve configured its key signing parameters correctly - though one thing that sticks out is the Yocto conf splits the FIT image keys into a separate conf and image key, whereas TCB’s config file section for kernel signing only prompts for the image signing key.

One note though - when I flashed only the bootloader it partially bricked the module due to OS/bootloader expectation mismatches. So I’m attempting to restore it without a full re-deploy via usb-storage mode in u-boot and extracting the OTA archive to the root of the eMMC. This seems to work since it correctly tracks expectations (debug output references stock DTBs if I do this with the yocto output, references my custom DTB if I extract the TCB output) but of course it’s another variable at play.

8

I did already try a clean rebuild and forcing a u-boot and kernel recompile

Just to clarify here, are you saying you did a build from scratch and it still did not work?

Also did you try the method to manually generate and provide keys to the build, rather than relying on the auto-generated keys? Did that make any difference?

Best Regards,
Jeremias

9

I figured it out - the issue was incorrect key selection in tcbuild.yaml. Since the comments seem to imply the key is for signing the kernel and u-boot (images) I had specified the fit-image-1 key.

Changing the specified key to fit-conf-1 fixed the issue and it booted without issue.

I’m still unclear about the role of both FIT keys if it seems like only one is actually used/embedded in u-boot, but at least I am no longer hitting this issue.

Edit: I understand better now - the Toradex flow uses a signed-configuration approach (rather than a signed-image approach) which is why only the conf-key is required. The image key is redundant if the actual selected conf and the images it specifies are signed.