+Cc Marek On 2/16/25 7:36 PM, Rogerio Guerra Borin via lists.openembedded.org wrote:
You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hello,At Toradex we're using class "kernel-fitimage" to produce our signed kernel FIT images and we've found that the recent commit d7bd9c627661 ("u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enabled") broke our builds. The logs of a failed build show the following message that I found noteworthy: log.do_uboot_assemble_fitimage.841485: ... Couldn't open RSA private key: '/secboot-data/fit-keys/dev2.key': No such file or directory The odd thing was that the build was setting: UBOOT_SIGN_KEYNAME = "dev" UBOOT_SIGN_IMG_KEYNAME = "dev2" FIT_SIGN_INDIVIDUAL = "0" FIT_GENERATE_KEYS = "0" From the above we see the individual images signing is disabled but the system is trying to access the key file for the individual signing (dev2) regardless of that. Checking the code in uboot-sign.bbclass I found this line: https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/uboot-sign.bbclass?h=scarthgap#n116 that is responsible for that access (inside function concat_dtb()). The code is always referencing variable UBOOT_SIGN_IMG_KEYNAME regardless of FIT_SIGN_INDIVIDUAL being set to "1" or "0" even though there's a condition a couple lines above L116 where FIT_SIGN_INDIVIDUAL is tested to decide in which mode to run the signing tool. To better understand the behavior I created dev2.{key,crt} files and retried a build which worked. However, checking the contents of the final u-boot.dtb file I found that the "dev2" key node was present but the "dev" key wasn't. Then, checking the contents of the final fitImage I noticed the configuration nodes were signed by the dev key while the individual images were not signed (as expected). But that means such a system wouldn't boot since the required "dev" key is not present in the U-Boot DTB, from what I conclude the FIT signing is broken at the moment. So, first of all I wanted to let you guys know about this issue (hoping we're not doing anything wrong with our builds). As a second point, I wanted to confirm the expected behavior regarding variable FIT_SIGN_INDIVIDUAL. According to the documentation: https://docs.yoctoproject.org/5.0.6/ref-manual/variables.html#term-FIT_SIGN_INDIVIDUAL when its value is "1" the individual images will be signed *in addition* to the FIT image being signed. From that, I understand that the configurations will be always signed and the individual images may or may not be signed depending on FIT_SIGN_INDIVIDUAL. I kind of confirmed this behavior by checking our build artifacts on kirkstone: with FIT_SIGN_INDIVIDUAL="0" the U-Boot DTB has only the "dev" key and the fit image is signed by that same key; with FIT_SIGN_INDIVIDUAL="1" both keys are present in the DTB, the configurations are signed by the "dev" key and the images by the "dev2" key. I understand this is the correct behavior, right? I'm asking because looking at the comment at: https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/uboot-sign.bbclass?h=scarthgap#n106 it gives me the impression that FIT_SIGN_INDIVIDUAL would select between either signing individual images or signing the configurations, which doesn't match the documented behavior. I believe the code in concat_dtb() also seems to assume only one of the keys (dev/dev2) would need be present in the DTB. So the fix would involve a review on this as well I imagine.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#211537): https://lists.openembedded.org/g/openembedded-core/message/211537 Mute This Topic: https://lists.openembedded.org/mt/111218371/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
