kernel-fit-image: Split signing variables

Right now all signing is done with a single variable: UBOOT_SIGN_ENABLE.
This has the side effect of not allowing for signing the fitImage while
not signing the uboot files.

This patch creates three new variables specific to KERNEL_FITIMAGE and
defaults them to the corresponding UBOOT variables.  That way all
existing code will remain the same, but we can selectively control just
signing the fitImage without also signing the uboot files.

Signed-off-by: Ryan Eatmon <reatmon@ti.com>
---
 meta/classes-recipe/kernel-fit-image.bbclass | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Am Do., 16. Okt. 2025 um 15:58 Uhr schrieb Ryan Eatmon via
lists.openembedded.org <reatmon=ti.com@lists.openembedded.org>:

> Right now all signing is done with a single variable: UBOOT_SIGN_ENABLE.
> This has the side effect of not allowing for signing the fitImage while
> not signing the uboot files.
>
> This patch creates three new variables specific to KERNEL_FITIMAGE and
> defaults them to the corresponding UBOOT variables.  That way all
> existing code will remain the same, but we can selectively control just
> signing the fitImage without also signing the uboot files.
>
> Signed-off-by: Ryan Eatmon <reatmon@ti.com>
> ---
>  meta/classes-recipe/kernel-fit-image.bbclass | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes-recipe/kernel-fit-image.bbclass
> b/meta/classes-recipe/kernel-fit-image.bbclass
> index f04aee1807..29f4098ccc 100644
> --- a/meta/classes-recipe/kernel-fit-image.bbclass
> +++ b/meta/classes-recipe/kernel-fit-image.bbclass
> @@ -35,6 +35,10 @@ do_configure[noexec] = "1"
>  UBOOT_MKIMAGE_KERNEL_TYPE ?= "kernel"
>  KERNEL_IMAGEDEST ?= "/boot"
>
> +KERNEL_FITIMAGE_SIGN_ENABLE ?= "${UBOOT_SIGN_ENABLE}"
> +KERNEL_FITIMAGE_SIGN_KEYNAME ?= "${UBOOT_SIGN_KEYNAME}"
> +KERNEL_FITIMAGE_SIGN_KEYDIR ?= "${UBOOT_SIGN_KEYDIR}"
> +
>

This kind of introduces a new namespace KERNEL_FITIMAGE_.
However, there are already namespaces which we could re-use.
Would that be better?

FIT_KERNEL_SIGN_ENABLE ?= "${UBOOT_SIGN_ENABLE}"
FIT_KERNEL_SIGN_KEYNAME ?= "${UBOOT_SIGN_KEYNAME}"
FIT_KERNEL_SIGN_KEYDIR ?= "${UBOOT_SIGN_KEYDIR}"

It would also be interesting to understand your use case, because signing
the FIT
image usually requires a bootloader which can verify the signature at
run-time.
Your patch basically removes the deployment of the public key into
u-boot's DTB.
Do you use a different bootloader?

Regards
Adrian



>  python do_compile() {
>      import shutil
>      import oe.fitimage
> @@ -50,11 +54,11 @@ python do_compile() {
>      root_node = oe.fitimage.ItsNodeRootKernel(
>          d.getVar("FIT_DESC"), d.getVar("FIT_ADDRESS_CELLS"),
>          d.getVar('HOST_PREFIX'), d.getVar('UBOOT_ARCH'),
> d.getVar("FIT_CONF_PREFIX"),
> -        oe.types.boolean(d.getVar('UBOOT_SIGN_ENABLE')),
> d.getVar("UBOOT_SIGN_KEYDIR"),
> +        oe.types.boolean(d.getVar('KERNEL_FITIMAGE_SIGN_ENABLE')),
> d.getVar("KERNEL_FITIMAGE_SIGN_KEYDIR"),
>          d.getVar("UBOOT_MKIMAGE"), d.getVar("UBOOT_MKIMAGE_DTCOPTS"),
>          d.getVar("UBOOT_MKIMAGE_SIGN"),
> d.getVar("UBOOT_MKIMAGE_SIGN_ARGS"),
>          d.getVar('FIT_HASH_ALG'), d.getVar('FIT_SIGN_ALG'),
> d.getVar('FIT_PAD_ALG'),
> -        d.getVar('UBOOT_SIGN_KEYNAME'),
> +        d.getVar('KERNEL_FITIMAGE_SIGN_KEYNAME'),
>          oe.types.boolean(d.getVar('FIT_SIGN_INDIVIDUAL')),
> d.getVar('UBOOT_SIGN_IMG_KEYNAME')
>      )
>
> --
> 2.17.1
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#224965):
> https://lists.openembedded.org/g/openembedded-core/message/224965
> Mute This Topic: https://lists.openembedded.org/mt/115789309/4454582
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> adrian.freihofer@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

On 10/20/2025 1:39 AM, Adrian Freihofer wrote:
> Am Do., 16. Okt. 2025 um 15:58 Uhr schrieb Ryan Eatmon via 
> lists.openembedded.org <http://lists.openembedded.org> 
> <reatmon=ti.com@lists.openembedded.org 
> <mailto:ti.com@lists.openembedded.org>>:
> 
>     Right now all signing is done with a single variable: UBOOT_SIGN_ENABLE.
>     This has the side effect of not allowing for signing the fitImage while
>     not signing the uboot files.
> 
>     This patch creates three new variables specific to KERNEL_FITIMAGE and
>     defaults them to the corresponding UBOOT variables.  That way all
>     existing code will remain the same, but we can selectively control just
>     signing the fitImage without also signing the uboot files.
> 
>     Signed-off-by: Ryan Eatmon <reatmon@ti.com <mailto:reatmon@ti.com>>
>     ---
>       meta/classes-recipe/kernel-fit-image.bbclass | 8 ++++++--
>       1 file changed, 6 insertions(+), 2 deletions(-)
> 
>     diff --git a/meta/classes-recipe/kernel-fit-image.bbclass b/meta/
>     classes-recipe/kernel-fit-image.bbclass
>     index f04aee1807..29f4098ccc 100644
>     --- a/meta/classes-recipe/kernel-fit-image.bbclass
>     +++ b/meta/classes-recipe/kernel-fit-image.bbclass
>     @@ -35,6 +35,10 @@ do_configure[noexec] = "1"
>       UBOOT_MKIMAGE_KERNEL_TYPE ?= "kernel"
>       KERNEL_IMAGEDEST ?= "/boot"
> 
>     +KERNEL_FITIMAGE_SIGN_ENABLE ?= "${UBOOT_SIGN_ENABLE}"
>     +KERNEL_FITIMAGE_SIGN_KEYNAME ?= "${UBOOT_SIGN_KEYNAME}"
>     +KERNEL_FITIMAGE_SIGN_KEYDIR ?= "${UBOOT_SIGN_KEYDIR}"
>     +
> 
> 
> This kind of introduces a new namespace KERNEL_FITIMAGE_.
> However, there are already namespaces which we could re-use.
> Would that be better?
> 
> FIT_KERNEL_SIGN_ENABLE ?= "${UBOOT_SIGN_ENABLE}"
> FIT_KERNEL_SIGN_KEYNAME ?= "${UBOOT_SIGN_KEYNAME}"
> FIT_KERNEL_SIGN_KEYDIR ?= "${UBOOT_SIGN_KEYDIR}"

I'm fine with that.  I'll send a v2.


> It would also be interesting to understand your use case, because 
> signing the FIT
> image usually requires a bootloader which can verify the signature at 
> run-time.
> Your patch basically removes the deployment of the public key into u- 
> boot's DTB.
> Do you use a different bootloader?

We are using u-boot, but we are making use of the UBOOT_CONFIG flow to 
build multiple versions of the u-boot files at the same time.  Sometimes 
we build different configs, sometimes we just want to change the make 
command line options when building the same config.  In the UBOOT_CONFIG 
flow, the last variation in the list because the "default" variation for 
the main uboot files and what aligns with the fitImage as the "default" 
out of the build.

We then use the individual files in our testing by uploading the image 
files over uart to our boards and booting from there.

Second piece of background, our u-boot files are all signed by the 
binman flow within the u-boot build process.  So oe-core signing them a 
second time is not needed.

In this specific case, one variation we are trying to build is our main 
config but sign all of the files using a different key type (ecdsa) to 
test out that our board and software work correctly.  But we ran into 
the problem that UBOOT_SIGN_ENABLE was re-signing the files using the 
"default" key and not the key that we had already signed them with.

So we need the fitImage signing for the default set of files, but we do 
not want the u-boot file signing since they are already signed by the 
u-boot build itself.

Hope that helps clarify...