u-boot-stm32mp: Fix fit signing

[UVV-gh]

ST implementation of signing conflicts with the one from oe-core from uboot-sign class. This is just a sample fix, which you can use, but I would rather rework it completely by reverting bee6a4b in the first place and use what's already present in oe-core.

Right now the implementation looks like a copy-paste of signing code from uboot-sign class, which also omits a few details and forces users to always set FIT_SIGN_INDIVIDUAL.

Without this fix the build works, but when you try to boot you'll get a verification failed error:

Verification failed for '<NULL>' hash node in 'conf-<name>.dtb' config node
Failed to verify required signature 'key-'
Bad Data Hash

[BernardPuel]

Hello,
Thanks a lot for your inputs.

I understand you would like to have a implementation closer to oe-core tools. The proposed patch will probably also break some other mechanism. We will check this.

Now, current implementation is supposed to work like this (maybe not like you would wish).
The way to enable it is described here: https://wiki.st.com/stm32mpu/wiki/How_to_create_Signed_FIT_image_from_Distribution_package

Did you follow this wiki for your test ?

[BernardPuel]

For everyone's, please be aware v6.1.1 brings major correction on this use case. see: https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ecosystem_release_note#v6.1.1

[yassibeh]

Confirming regression: Signed FIT key selection injects the wrong public key into U-Boot DTB

I can reproduce the issue described in this ticket. It matches the “wrong key injected into U-Boot DTB” class of problem and breaks Signed FIT setups (especially with FIT_SIGN_INDIVIDUAL="0", the recommended mode).

1. How to reproduce (minimal)

1. Follow the ST wiki procedure:
   https://wiki.st.com/stm32mpu/wiki/How_to_create_Signed_FIT_image_from_Distribution_package

2. ST ecosystem release note v6.1.1 mentions “updates for FIT image signature”:
   https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ecosystem_release_note#v6.1.1

3. Generate keys and set variables as in the ST wiki (example values):

   • UBOOT_SIGN_KEYDIR = "<absolute path>"
   • UBOOT_SIGN_KEYNAME = "uboot-sign-key"
   • UBOOT_SIGN_IMG_KEYNAME = "uboot-img-sign-key"
   • UBOOT_SIGN_ENABLE = "1"
   • FIT_GENERATE_KEYS = "0"
   • FIT_SIGN_INDIVIDUAL = "0" (also reproduces with "1" depending on the exact code path)

4. Build U-Boot and the kernel FIT image (u-boot-stm32mp + linux-stm32mp / image build).

2. What is the issue

When building a signed kernel FIT image, the public key injected into the U-Boot DTB does not match the key actually used to sign the FIT configuration (conf) nodes.

Typical outcomes:

1. Build-time failure (common with FIT_SIGN_INDIVIDUAL="0"):
   the build tries to access the “image key” (UBOOT_SIGN_IMG_KEYNAME) even though individual image signing is disabled.
2. Boot-time failure:
   U-Boot cannot verify the required signature because the DTB contains the wrong required key, leading to errors such as:
   • Failed to verify required signature ...
   • Bad Data Hash
   • Verification failed ...

3. Minimal reproduction variant (shows the bug clearly)

1. Use the same Signed FIT flow, but with the classic upstream example variables:

   • UBOOT_SIGN_ENABLE = "1"
   • UBOOT_SIGN_KEYNAME = "dev"
   • UBOOT_SIGN_IMG_KEYNAME = "dev2"
   • FIT_SIGN_INDIVIDUAL = "0"
   • FIT_GENERATE_KEYS = "0"

2. Provide only the config key material (dev.{key,crt}) in UBOOT_SIGN_KEYDIR (no dev2.*), then build.

Result: the build fails (or later boot verification fails) because DTB key injection does not match the signing mode.

4. Why the proposed fix makes sense (expected behavior)

The fix should ensure that:

1. When signing configurations (safe/recommended path, FIT_SIGN_INDIVIDUAL="0"), the key injected into the U-Boot DTB for configuration verification uses UBOOT_SIGN_KEYNAME (mkimage auto-conf mode).
2. The image key UBOOT_SIGN_IMG_KEYNAME is used/injected only when individual image signing is enabled (FIT_SIGN_INDIVIDUAL="1", mkimage auto mode), and only for that path.

This prevents the DTB “required key” mismatch and aligns with the upstream OE-Core behavior in uboot-sign.bbclass.

5. References

• ST wiki Signed FIT procedure:
  https://wiki.st.com/stm32mpu/wiki/How_to_create_Signed_FIT_image_from_Distribution_package

• ST ecosystem release note v6.1.1 (“updates for FIT image signature”):
  https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ecosystem_release_note#v6.1.1

• Upstream OE-Core behavior (uboot-sign.bbclass):
  https://github.com/openembedded/openembedded-core/blob/master/meta/classes-recipe/uboot-sign.bbclass

• Upstream discussion about the regression:
  https://lists.openembedded.org/g/openembedded-core/topic/broken_fit_image_signing/111218371

• Related ST PRs proposing similar fixes:

  • u-boot-stm32mp: Fix fit signing #105 (commit 6eb91fa4861125a7a8c6ef8bb6771a8da51eff41)
  • u-boot-stm32mp: Fix FIT signing process #106 (commit 17dd90c1979e022138eaa7d56db875dda8c62213)

[BernardPuel]

Correction will be delivered on v6.2.0 (Wk08).