[PATCH 0/3] fit: allow signing with only an engine_id

[Quentin Schulz]

Hi Wolfgang,

On 11/11/25 11:10 AM, Wolfgang Wallner wrote:
> Hi Quentin,
> 
>> This series allows to sign a FIT image with mkimage (and binman) with
>> only an OpenSSL engine and no key-dir. mkimage will read the
>> key-name-hint property and pass that verbatim to the OpenSSL engine API
>> via the key_id argument.
> 
> Thanks for implementing this!
> I was already looking for a way to implement this myself when I saw your
> implementation on the mailing list.
> 
> I have tested your patch series in our environment with our PKI provider.
> Our PKI provider supports the OpenSSL engine API with a PKCS#11 library.
> 
> Signing and verification with your patch series works fine in our use case.
> 
> I only stumbled over a small issue, but that has nothing to with your patch
> series:
> Initially I used the same key-name-hint in the FIT description for
> U-Boot proper (which is then used by mkimage for signing) and in the
> description for U-Boot SPL (within an u-boot-spl-pubkey-dtb entry).
> In my case key-name-hint contains a colon and several equation signs, it looks
> something like this:
> 
>      key-name-hint = "pkcs11:model=xxx;manufacturer=xxx;serial=1234;token=xxx;id=xxx;object=xxx";
> 
> But when I do this, I cannot decompile the final SPL devicetree any more.
> Decompiling with dtc gives me a "Bad character '=' in node name" error then.

The issue is probably that we use the key-name-hint for the key node in 
SPL DTB, c.f. 
https://elixir.bootlin.com/u-boot/v2025.10/source/lib/rsa/rsa-sign.c#L677

We could sanitize the keyname to make sure it's an appropriate name for 
a DT node. According to the standard, allowed characters are

[0-9][a-z][A-Z],._+-

and the node name shall start with a letter. We could iterate over the 
string and replace any unsupported character.

We shall do the same for when we try to find this key node, 
https://elixir.bootlin.com/u-boot/v2025.10/source/boot/image-fit-sig.c#L87 
and/or 
https://elixir.bootlin.com/u-boot/v2025.10/source/lib/rsa/rsa-verify.c#L538.

> As a workaround, I use a different key-name-hint in the SPL description now.
> But as mentioned above, this is just something I found while testing your
> patches, nothing caused by them.
> 

Can you show us a snippet of how this looks like? Because as far as I 
could tell, the key-name-hint in the SPL pubkey DTB must match the 
key-name-hint used for each signature node in the U-Boot proper FIT 
image. But I assume the key-name-hint for you is used to pass parameters 
to the engine, so you cannot really NOT have it named this way?

Maybe we should split the double meaning of key-name-hint which is both 
for identifying the signature to use and how to sign into two separate 
properties.

> This series is useful for us, and I'm happy to assist with further testing and
> review. I'm not sure if I can help with creating tests, but I will have a look
> at the things Simon listed.
> 

I'll look into mocking the calls to mkimage for testing the binman part 
correctly calls mkimage but I think we should also think about adding 
test for (engine) signing with mkimage (and maybe even verify that the 
generated images work with sandbox for example).

I would also very much like to have a way to sign Rockchip images with 
the default binman instructions in rockchip-u-boot.dtsi, but this is 
currently not possible for multiple reasons.

1) we misuse/abuse SPL_FIT_SIGNATURE without an actual signature/pubkey, 
only for verifying hashes. We should sign the image and add the pubkey 
if SPL_FIT_SIGNATURE is enabled, and fail if it cannot find a key, but 
we cannot do that because it would break current users. We would need to 
split the "check hash" from "verify hash with signature" functionality 
behind another Kconfig symbol for that. I don't think it cannot be done, 
but we need to be careful to avoid forgetting about checking hashes when 
signature is enabled.

2) Make most of the signing configurable through environment variables. 
key-name-hint, whether to use an engine and if so which one, the 
checksum algorithm in algo property, the crypto used (RSA/ECDSA) and its 
key size or whatever other parameter passed to the algo property, the 
padding type (PSS/PKCS) and salt length. I believe we shouldn't make 
those part of the hardcoded binman configuration in DT or from defconfig 
because there is no reason to patch the tree (DT or defconfig) to change 
signatures for essentially the same binaries. We could have environment 
variables used in the binman node in DT though (but for that to work, we 
need to pass environment variables to dtc via flags, or create Kconfig 
symbols generated from env variables). This means many environment 
variables to document and test. Not sure the project wants to go that 
direction though. I would also want this to be something followed by all 
architectures, not simply Rockchip, otherwise enabling SPL_FIT_SIGNATURE 
simply isn't doing what it says it's doing (I can boot unsigned images 
without any issue from current master, which kinda breaks what 
SPL_FIT_SIGNATURE seems to be hinting at "Enable signature verification 
of FIT firmware within SPL").

I'm planning on sending a mail in the next few weeks to ask what would 
be acceptable for 2) but I am not sure this will go anywhere to be honest.
I think implementing a new feature for checking hashes without signing 
(1)) makes sense and is unrelated to/not a blocker for 2).

Cheers,
Quentin