From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB86BC02198 for ; Sun, 16 Feb 2025 18:36:24 +0000 (UTC) Subject: Broken FIT image signing since "u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enabled" To: openembedded-core@lists.openembedded.org From: "Rogerio Guerra Borin" X-Originating-Location: =?UTF-8?B?U8OjbyBQYXVsbywgU2FvIFBhdWxvLCBCUg==?= (189.33.122.79) X-Originating-Platform: Linux Firefox 134 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Sun, 16 Feb 2025 10:36:23 -0800 Message-ID: Content-Type: multipart/alternative; boundary="fDs55NpUKNX6TxUMsX2j" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Sun, 16 Feb 2025 18:36:24 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/211507 --fDs55NpUKNX6TxUMsX2j Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: k= ernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enab= led") broke our builds. The logs of a failed build show the following messa= ge that I found noteworthy: log.do_uboot_assemble_fitimage.841485: ... Couldn't open RSA private key: '/secboot-data/fit-keys/dev2.key': No such f= ile or directory The odd thing was that the build was setting: UBOOT_SIGN_KEYNAME =3D "dev" UBOOT_SIGN_IMG_KEYNAME =3D "dev2" FIT_SIGN_INDIVIDUAL =3D "0" FIT_GENERATE_KEYS =3D "0" >From the above we see the individual images signing is disabled but the sys= tem is trying to access the key file for the individual signing (dev2) rega= rdless of that. Checking the code in uboot-sign.bbclass I found this line: https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/ubo= ot-sign.bbclass?h=3Dscarthgap#n116 that is responsible for that access (inside function concat_dtb()). The cod= e is always referencing variable UBOOT_SIGN_IMG_KEYNAME regardless of FIT_S= IGN_INDIVIDUAL being set to "1" or "0" even though there's a condition a co= uple lines above L116 where FIT_SIGN_INDIVIDUAL is tested to decide in whic= h 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 t= he contents of the final u-boot.dtb file I found that the "dev2" key node w= as present but the "dev" key wasn't. Then, checking the contents of the fin= al fitImage I noticed the configuration nodes were signed by the dev key wh= ile the individual images were not signed (as expected). But that means suc= h 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 vari= able 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 configuration= s 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 chec= king our build artifacts on kirkstone: with FIT_SIGN_INDIVIDUAL=3D"0" the U= -Boot DTB has only the "dev" key and the fit image is signed by that same k= ey; with FIT_SIGN_INDIVIDUAL=3D"1" both keys are present in the DTB, the co= nfigurations 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/ubo= ot-sign.bbclass?h=3Dscarthgap#n106 it gives me the impression that FIT_SIGN_INDIVIDUAL would select between ei= ther signing individual images or signing the configurations, which doesn't= match the documented behavior. I believe the code in concat_dtb() also see= ms to assume only one of the keys (dev/dev2) would need be present in the D= TB. So the fix would involve a review on this as well I imagine. --fDs55NpUKNX6TxUMsX2j Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hello,
 
At Toradex we're using class "kernel-fitimage" to produce our signed k= ernel FIT images and we've found that the recent commit d7bd9c627661 ("u-bo= ot: 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.ke= y': No such file or directory
 
The odd thing was that the build was setting:
 
UBOOT_SIGN_KEYNAME =3D "dev"
UBOOT_= SIGN_IMG_KEYNAME =3D "dev2"
FIT_SIGN_INDIVIDUAL =3D "0"
FIT_GENER= ATE_KEYS =3D "0"
 
From the above we see the individual images signing is disabled but th= e 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 l= ine:
 
https://git.openembedded.org/openembedded-core/tree/meta/classes-recip= e/uboot-sign.bbclass?h=3Dscarthgap#n116
 
that is responsible for that access (inside function concat_dtb()). Th= e 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 cr= eated dev2.{key,crt} files and retried a build which worked. However, check= ing the contents of the final u-boot.dtb file I found that the "dev2" key n= ode was present but the "dev" key wasn't. Then, checking the contents of th= e final fitImage I noticed the configuration nodes were signed by the dev k= ey while the individual images were not signed (as expected). But that mean= s such a system wouldn't boot since the required "dev" key is not present i= n the U-Boot DTB, from what I conclude the FIT signing is broken at the mom= ent.
 
So, first of all I wanted to let you guys know about this issue (hopin= g 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:
 
 
when its value is "1" the individual images will be signed *in additio= n* to the FIT image being signed. From that, I understand that the configur= ations will be always signed and the individual images may or may not be si= gned depending on FIT_SIGN_INDIVIDUAL. I kind of confirmed this behavior by= checking our build artifacts on kirkstone: with FIT_SIGN_INDIVIDUAL=3D"0" = the U-Boot DTB has only the "dev" key and the fit image is signed by that s= ame key; with FIT_SIGN_INDIVIDUAL=3D"1" both keys are present in the DTB, t= he 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:
 
 
it gives me the impression that FIT_SIGN_INDIVIDUAL would select betwe= en either signing individual images or signing the configurations, which do= esn't match the documented behavior. I believe the code in concat_dtb() als= o 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.
 
--fDs55NpUKNX6TxUMsX2j--