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
