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

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

[Quentin Schulz]

I have a couple of products whose U-Boot FIT is signed via a proprietary
OpenSSL engine which only expects the name of a "slot" to select the key
to sign data with.

Currently mkimage fit support expects either a key-dir (-k) or a
key-file (-G) as a toggle for signing, however this doesn't apply to our
usecase because we use an OpenSSL engine (so no key-file to provide)
which doesn't mimic a directory layout like key-dir implies. Moreover,
binman really expects private keys (.key extension) to be available in
this key-dir directory, which we of course cannot provide.

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.

Note that the public key (.crt extension) still needs to be available if
one wants to embed it for signature verification (which is probably what
one wants to do :) ).

One issue though is that since binman resolves key paths absolutely and
that I don't believe an OpenSSL engine would happen to have the exact
same key_id value than a local absolute path, fit,encrypt and
fit,sign-engine cannot cohabit. An issue for the next person who wants
an OpenSSL engine AND encrypt the same FIT image, I don't.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
Quentin Schulz (3):
      fit: support signing with only an engine_id
      tools: binman: mkimage: add support for passing the engine
      tools: binman: fit: add support for OpenSSL engines

 tools/binman/btool/mkimage.py |  5 ++++-
 tools/binman/entries.rst      | 22 +++++++++++++++++++---
 tools/binman/etype/fit.py     | 41 +++++++++++++++++++++++++++++++++++++----
 tools/fit_image.c             |  3 ++-
 tools/image-host.c            |  4 ++--
 5 files changed, 64 insertions(+), 11 deletions(-)
---
base-commit: 0dad93a72ec59b21cedeab365a28fcaa11a58384
change-id: 20251030-binman-engine-e349b02696d0

Best regards,
-- 
Quentin Schulz <quentin.schulz@cherry.de>

[PATCH 1/3] fit: support signing with only an engine_id

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

Currently, when one wants to use an OpenSSL engine to sign a FIT image,
one needs to pass a keydir (via -k) to mkimage which will then be
prepended to the value of the key-name-hint before being passed as
key_id argument to the OpenSSL Engine API, or pass a keyfile (via -G) to
mkimage.

My OpenSSL engine only has "slots" which are not mapped like
directories, so using keydir is not proper, though I could simply have
-k '' I guess but this won't work currently with binman anyway.

Additionally, passing a keyfile when using an engine doesn't make sense
as the key is stored in the engine.

Let simply allow FIT images be signed if both keydir and keyfile are
missing but an engine is to be used.

The keyname member is already filled by looking at key-name-hint
property in the FIT and passed verbatim to the engine, which is exactly
what is needed here.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 tools/fit_image.c  | 3 ++-
 tools/image-host.c | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/fit_image.c b/tools/fit_image.c
index 0306333141e..694bb927c7d 100644
--- a/tools/fit_image.c
+++ b/tools/fit_image.c
@@ -26,7 +26,8 @@ static struct legacy_img_hdr header;
 
 static int fit_estimate_hash_sig_size(struct image_tool_params *params, const char *fname)
 {
-	bool signing = IMAGE_ENABLE_SIGN && (params->keydir || params->keyfile);
+	bool signing = IMAGE_ENABLE_SIGN &&
+		(params->keydir || params->keyfile || params->engine_id);
 	struct stat sbuf;
 	void *fdt;
 	int fd;
diff --git a/tools/image-host.c b/tools/image-host.c
index 21dd7f2d922..54df86316ae 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -696,7 +696,7 @@ int fit_image_add_verification_data(const char *keydir, const char *keyfile,
 			     strlen(FIT_HASH_NODENAME))) {
 			ret = fit_image_process_hash(fit, image_name, noffset,
 						data, size);
-		} else if (IMAGE_ENABLE_SIGN && (keydir || keyfile) &&
+		} else if (IMAGE_ENABLE_SIGN && (keydir || keyfile || engine_id) &&
 			   !strncmp(node_name, FIT_SIG_NODENAME,
 				strlen(FIT_SIG_NODENAME))) {
 			ret = fit_image_process_sig(keydir, keyfile, keydest,
@@ -1366,7 +1366,7 @@ int fit_add_verification_data(const char *keydir, const char *keyfile,
 	}
 
 	/* If there are no keys, we can't sign configurations */
-	if (!IMAGE_ENABLE_SIGN || !(keydir || keyfile))
+	if (!IMAGE_ENABLE_SIGN || !(keydir || keyfile || engine_id))
 		return 0;
 
 	/* Find configurations parent node offset */

-- 
2.51.0

[PATCH 2/3] tools: binman: mkimage: add support for passing the engine

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

mkimage has support for OpenSSL engines but binman currently doesn't for
direct callers of mkimage (e.g. the fit etype). This prepares for adding
support for OpenSSL engines for signing elements of a FIT image, which
will done in the next commit.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 tools/binman/btool/mkimage.py | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/binman/btool/mkimage.py b/tools/binman/btool/mkimage.py
index 3f84220fb1a..79a8f887795 100644
--- a/tools/binman/btool/mkimage.py
+++ b/tools/binman/btool/mkimage.py
@@ -22,7 +22,7 @@ class Bintoolmkimage(bintool.Bintool):
 
     # pylint: disable=R0913
     def run(self, reset_timestamp=False, output_fname=None, external=False,
-            pad=None, align=None, keys_dir=None):
+            pad=None, align=None, keys_dir=None, engine=None):
         """Run mkimage
 
         Args:
@@ -35,6 +35,7 @@ class Bintoolmkimage(bintool.Bintool):
                 signatures
             align: Bytes to use for alignment of the FIT and its external data
             keys_dir: Path to directory containing private and encryption keys
+            engine: Name of the OpenSSL engine to use
             version: True to get the mkimage version
         """
         args = []
@@ -50,6 +51,8 @@ class Bintoolmkimage(bintool.Bintool):
             args += ['-k', f'{keys_dir}']
         if output_fname:
             args += ['-F', output_fname]
+        if engine:
+            args += ['-N', engine]
         return self.run_cmd(*args)
 
     def fetch(self, method):

-- 
2.51.0

[PATCH 3/3] tools: binman: fit: add support for OpenSSL engines

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@cherry.de>

This adds support for using an OpenSSL engine for signing a FIT image.
To use it, one should set the fit,sign-engine property at the FIT node
level with the engine to use. This will in turn call mkimage with the -N
option.

The key-name-hint property in the signature node will be used verbatim
as key_id in OpenSSL engine API.

We could somehow still decide to pass some keys_dir to mkimage when
signing with an engine is enabled (mkimage does support that!),
unfortunately binman resolves key paths absolutely. I don't believe an
OpenSSL engine will happen to have the exact same key_id than the path
to the encryption key, so fit,encrypt and fit,sign-engine cannot
cohabit.

The public key (with .crt extension) is still required if it needs to be
embedded in the SPL DTB for example.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
 tools/binman/entries.rst  | 22 +++++++++++++++++++---
 tools/binman/etype/fit.py | 41 +++++++++++++++++++++++++++++++++++++----
 2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 8922d6cd070..7b162a3edb8 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -885,9 +885,10 @@ The top-level 'fit' node supports the following special properties:
 
     fit,sign
         Enable signing FIT images via mkimage as described in
-        verified-boot.rst. If the property is found, the private keys path
-        is detected among binman include directories and passed to mkimage
-        via  -k flag. All the keys required for signing FIT must be
+        verified-boot.rst.
+        If the property is found and fit,sign-engine is not set, the private
+        keys path is detected among binman include directories and passed to
+        mkimage via -k flag. All the keys required for signing FIT must be
         available at time of signing and must be located in single include
         directory.
 
@@ -898,6 +899,21 @@ The top-level 'fit' node supports the following special properties:
         required for encrypting the FIT must be available at the time of
         encrypting and must be located in a single include directory.
 
+        Incompatible with fit,sign-engine.
+
+    fit,sign-engine
+        Indicates the OpenSSL engine to use for signing the FIT image. This
+        is passed to mkimage via the `-N` flag. Example::
+
+            fit,sign-engine = "my-engine";
+
+        No `-k` argument will be passed to mkimage. The key_id passed to the
+        OpenSSL engine API is the verbatim value of the key-name-hint property.
+
+        Depends on fit,sign.
+
+        Incompatible with fit,encrypt.
+
 Substitutions
 ~~~~~~~~~~~~~
 
diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
index db40479d30e..df4cc9b749c 100644
--- a/tools/binman/etype/fit.py
+++ b/tools/binman/etype/fit.py
@@ -104,9 +104,10 @@ class Entry_fit(Entry_section):
 
         fit,sign
             Enable signing FIT images via mkimage as described in
-            verified-boot.rst. If the property is found, the private keys path
-            is detected among binman include directories and passed to mkimage
-            via  -k flag. All the keys required for signing FIT must be
+            verified-boot.rst.
+            If the property is found and fit,sign-engine is not set, the private
+            keys path is detected among binman include directories and passed to
+            mkimage via -k flag. All the keys required for signing FIT must be
             available at time of signing and must be located in single include
             directory.
 
@@ -117,6 +118,21 @@ class Entry_fit(Entry_section):
             required for encrypting the FIT must be available at the time of
             encrypting and must be located in a single include directory.
 
+            Incompatible with fit,sign-engine.
+
+        fit,sign-engine
+            Indicates the OpenSSL engine to use for signing the FIT image. This
+            is passed to mkimage via the `-N` flag. Example::
+
+                fit,sign-engine = "my-engine";
+
+            No `-k` argument will be passed to mkimage. The key_id passed to the
+            OpenSSL engine API is the verbatim value of the key-name-hint property.
+
+            Depends on fit,sign.
+
+            Incompatible with fit,encrypt.
+
     Substitutions
     ~~~~~~~~~~~~~
 
@@ -620,7 +636,24 @@ class Entry_fit(Entry_section):
             args.update({'align': fdt_util.fdt32_to_cpu(align.value)})
         if (self._fit_props.get('fit,sign') is not None or
             self._fit_props.get('fit,encrypt') is not None):
-            args.update({'keys_dir': self._get_keys_dir(data)})
+            engine = None
+            if self._fit_props.get('fit,sign') is not None:
+                engine_prop = self._fit_props.get('fit,sign-engine')
+                if engine_prop is not None:
+                    engine = engine_prop.value
+                    args.update({'engine': engine})
+            # Don't pass a key-dir to mkimage in case an engine is used to sign
+            # as we don't need a private key on storage anyway.
+            # Additionally, binman pass an absolute path as keys_dir which is
+            # highly unlikely to actually make sense for engines.
+            # Because of that limitation, we currently cannot support at the
+            # same time fit,encrypt and fit,sign-engine.
+            # mkimage will read key-name-hint and pass it verbatim to the engine
+            # as key_id in the OpenSSL engine API instead.
+            if engine is None:
+                args.update({'keys_dir': self._get_keys_dir(data)})
+            elif self._fit_props.get('fit,encrypt') is not None:
+                self.Raise('Cannot have both fit,encrypt and fit,sign-engine')
         if self.mkimage.run(reset_timestamp=True, output_fname=output_fname,
                             **args) is None:
             if not self.GetAllowMissing():

-- 
2.51.0

Re: [PATCH 1/3] fit: support signing with only an engine_id

[Simon Glass]

Hi Quentin,

On Fri, 31 Oct 2025 at 16:23, Quentin Schulz <foss+uboot@0leil.net> wrote:
>
> From: Quentin Schulz <quentin.schulz@cherry.de>
>
> Currently, when one wants to use an OpenSSL engine to sign a FIT image,
> one needs to pass a keydir (via -k) to mkimage which will then be
> prepended to the value of the key-name-hint before being passed as
> key_id argument to the OpenSSL Engine API, or pass a keyfile (via -G) to
> mkimage.
>
> My OpenSSL engine only has "slots" which are not mapped like
> directories, so using keydir is not proper, though I could simply have
> -k '' I guess but this won't work currently with binman anyway.
>
> Additionally, passing a keyfile when using an engine doesn't make sense
> as the key is stored in the engine.
>
> Let simply allow FIT images be signed if both keydir and keyfile are
> missing but an engine is to be used.
>
> The keyname member is already filled by looking at key-name-hint
> property in the FIT and passed verbatim to the engine, which is exactly
> what is needed here.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
>  tools/fit_image.c  | 3 ++-
>  tools/image-host.c | 4 ++--
>  2 files changed, 4 insertions(+), 3 deletions(-)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

but it might be worth creating a static inline function in the header file
for the condition, since it is pretty long now.

> diff --git a/tools/fit_image.c b/tools/fit_image.c
> index 0306333141e..694bb927c7d 100644
> --- a/tools/fit_image.c
> +++ b/tools/fit_image.c
> @@ -26,7 +26,8 @@ static struct legacy_img_hdr header;
>
>  static int fit_estimate_hash_sig_size(struct image_tool_params *params,
const char *fname)
>  {
> -       bool signing = IMAGE_ENABLE_SIGN && (params->keydir ||
params->keyfile);
> +       bool signing = IMAGE_ENABLE_SIGN &&
> +               (params->keydir || params->keyfile || params->engine_id);
>         struct stat sbuf;
>         void *fdt;
>         int fd;
> diff --git a/tools/image-host.c b/tools/image-host.c
> index 21dd7f2d922..54df86316ae 100644
> --- a/tools/image-host.c
> +++ b/tools/image-host.c
> @@ -696,7 +696,7 @@ int fit_image_add_verification_data(const char
*keydir, const char *keyfile,
>                              strlen(FIT_HASH_NODENAME))) {
>                         ret = fit_image_process_hash(fit, image_name,
noffset,
>                                                 data, size);
> -               } else if (IMAGE_ENABLE_SIGN && (keydir || keyfile) &&
> +               } else if (IMAGE_ENABLE_SIGN && (keydir || keyfile ||
engine_id) &&
>                            !strncmp(node_name, FIT_SIG_NODENAME,
>                                 strlen(FIT_SIG_NODENAME))) {
>                         ret = fit_image_process_sig(keydir, keyfile,
keydest,
> @@ -1366,7 +1366,7 @@ int fit_add_verification_data(const char *keydir,
const char *keyfile,
>         }
>
>         /* If there are no keys, we can't sign configurations */
> -       if (!IMAGE_ENABLE_SIGN || !(keydir || keyfile))
> +       if (!IMAGE_ENABLE_SIGN || !(keydir || keyfile || engine_id))
>                 return 0;
>
>         /* Find configurations parent node offset */
>
> --
> 2.51.0
>

Regards,
Simon

Re: [PATCH 2/3] tools: binman: mkimage: add support for passing the engine

[Simon Glass]

Hi Quentin,

On Fri, 31 Oct 2025 at 16:23, Quentin Schulz <foss+uboot@0leil.net> wrote:
>
> From: Quentin Schulz <quentin.schulz@cherry.de>
>
> mkimage has support for OpenSSL engines but binman currently doesn't for
> direct callers of mkimage (e.g. the fit etype). This prepares for adding
> support for OpenSSL engines for signing elements of a FIT image, which
> will done in the next commit.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
>  tools/binman/btool/mkimage.py | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)

Please make sure this is tested.

>
> diff --git a/tools/binman/btool/mkimage.py b/tools/binman/btool/mkimage.py
> index 3f84220fb1a..79a8f887795 100644
> --- a/tools/binman/btool/mkimage.py
> +++ b/tools/binman/btool/mkimage.py
> @@ -22,7 +22,7 @@ class Bintoolmkimage(bintool.Bintool):
>
>      # pylint: disable=R0913
>      def run(self, reset_timestamp=False, output_fname=None,
external=False,
> -            pad=None, align=None, keys_dir=None):
> +            pad=None, align=None, keys_dir=None, engine=None):
>          """Run mkimage
>
>          Args:
> @@ -35,6 +35,7 @@ class Bintoolmkimage(bintool.Bintool):
>                  signatures
>              align: Bytes to use for alignment of the FIT and its
external data
>              keys_dir: Path to directory containing private and
encryption keys
> +            engine: Name of the OpenSSL engine to use
>              version: True to get the mkimage version
>          """
>          args = []
> @@ -50,6 +51,8 @@ class Bintoolmkimage(bintool.Bintool):
>              args += ['-k', f'{keys_dir}']
>          if output_fname:
>              args += ['-F', output_fname]
> +        if engine:
> +            args += ['-N', engine]
>          return self.run_cmd(*args)
>
>      def fetch(self, method):
>
> --
> 2.51.0
>

Regards,
Simon

Re: [PATCH 3/3] tools: binman: fit: add support for OpenSSL engines

[Simon Glass]

Hi Quentin,

On Fri, 31 Oct 2025 at 16:23, Quentin Schulz <foss+uboot@0leil.net> wrote:
>
> From: Quentin Schulz <quentin.schulz@cherry.de>
>
> This adds support for using an OpenSSL engine for signing a FIT image.
> To use it, one should set the fit,sign-engine property at the FIT node
> level with the engine to use. This will in turn call mkimage with the -N
> option.
>
> The key-name-hint property in the signature node will be used verbatim
> as key_id in OpenSSL engine API.
>
> We could somehow still decide to pass some keys_dir to mkimage when
> signing with an engine is enabled (mkimage does support that!),
> unfortunately binman resolves key paths absolutely. I don't believe an
> OpenSSL engine will happen to have the exact same key_id than the path
> to the encryption key, so fit,encrypt and fit,sign-engine cannot
> cohabit.
>
> The public key (with .crt extension) is still required if it needs to be
> embedded in the SPL DTB for example.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
>  tools/binman/entries.rst  | 22 +++++++++++++++++++---
>  tools/binman/etype/fit.py | 41 +++++++++++++++++++++++++++++++++++++----
>  2 files changed, 56 insertions(+), 7 deletions(-)
>

This will need a test.

> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index 8922d6cd070..7b162a3edb8 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -885,9 +885,10 @@ The top-level 'fit' node supports the following
special properties:
>
>      fit,sign
>          Enable signing FIT images via mkimage as described in
> -        verified-boot.rst. If the property is found, the private keys
path
> -        is detected among binman include directories and passed to
mkimage
> -        via  -k flag. All the keys required for signing FIT must be
> +        verified-boot.rst.
> +        If the property is found and fit,sign-engine is not set, the
private
> +        keys path is detected among binman include directories and
passed to
> +        mkimage via -k flag. All the keys required for signing FIT must
be
>          available at time of signing and must be located in single
include
>          directory.
>
> @@ -898,6 +899,21 @@ The top-level 'fit' node supports the following
special properties:
>          required for encrypting the FIT must be available at the time of
>          encrypting and must be located in a single include directory.
>
> +        Incompatible with fit,sign-engine.
> +
> +    fit,sign-engine
> +        Indicates the OpenSSL engine to use for signing the FIT image.
This
> +        is passed to mkimage via the `-N` flag. Example::
> +
> +            fit,sign-engine = "my-engine";
> +
> +        No `-k` argument will be passed to mkimage. The key_id passed to
the
> +        OpenSSL engine API is the verbatim value of the key-name-hint
property.
> +
> +        Depends on fit,sign.
> +
> +        Incompatible with fit,encrypt.
> +
>  Substitutions
>  ~~~~~~~~~~~~~
>
> diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
> index db40479d30e..df4cc9b749c 100644
> --- a/tools/binman/etype/fit.py
> +++ b/tools/binman/etype/fit.py
> @@ -104,9 +104,10 @@ class Entry_fit(Entry_section):
>
>          fit,sign
>              Enable signing FIT images via mkimage as described in
> -            verified-boot.rst. If the property is found, the private
keys path
> -            is detected among binman include directories and passed to
mkimage
> -            via  -k flag. All the keys required for signing FIT must be
> +            verified-boot.rst.
> +            If the property is found and fit,sign-engine is not set, the
private
> +            keys path is detected among binman include directories and
passed to
> +            mkimage via -k flag. All the keys required for signing FIT
must be
>              available at time of signing and must be located in single
include
>              directory.
>
> @@ -117,6 +118,21 @@ class Entry_fit(Entry_section):
>              required for encrypting the FIT must be available at the
time of
>              encrypting and must be located in a single include directory.
>
> +            Incompatible with fit,sign-engine.
> +
> +        fit,sign-engine
> +            Indicates the OpenSSL engine to use for signing the FIT
image. This
> +            is passed to mkimage via the `-N` flag. Example::
> +
> +                fit,sign-engine = "my-engine";
> +
> +            No `-k` argument will be passed to mkimage. The key_id
passed to the
> +            OpenSSL engine API is the verbatim value of the
key-name-hint property.
> +
> +            Depends on fit,sign.
> +
> +            Incompatible with fit,encrypt.
> +
>      Substitutions
>      ~~~~~~~~~~~~~
>
> @@ -620,7 +636,24 @@ class Entry_fit(Entry_section):
>              args.update({'align': fdt_util.fdt32_to_cpu(align.value)})
>          if (self._fit_props.get('fit,sign') is not None or
>              self._fit_props.get('fit,encrypt') is not None):
> -            args.update({'keys_dir': self._get_keys_dir(data)})
> +            engine = None
> +            if self._fit_props.get('fit,sign') is not None:
> +                engine_prop = self._fit_props.get('fit,sign-engine')
> +                if engine_prop is not None:
> +                    engine = engine_prop.value
> +                    args.update({'engine': engine})
> +            # Don't pass a key-dir to mkimage in case an engine is used
to sign
> +            # as we don't need a private key on storage anyway.
> +            # Additionally, binman pass an absolute path as keys_dir
which is
> +            # highly unlikely to actually make sense for engines.
> +            # Because of that limitation, we currently cannot support at
the
> +            # same time fit,encrypt and fit,sign-engine.
> +            # mkimage will read key-name-hint and pass it verbatim to
the engine
> +            # as key_id in the OpenSSL engine API instead.
> +            if engine is None:
> +                args.update({'keys_dir': self._get_keys_dir(data)})
> +            elif self._fit_props.get('fit,encrypt') is not None:
> +                self.Raise('Cannot have both fit,encrypt and
fit,sign-engine')

Put all that in a function? Then your comment could be in the function
comment.

>          if self.mkimage.run(reset_timestamp=True,
output_fname=output_fname,
>                              **args) is None:
>              if not self.GetAllowMissing():
>
> --
> 2.51.0
>

Regards,
Simon

Re: [PATCH 2/3] tools: binman: mkimage: add support for passing the engine

[Quentin Schulz]

Hi Simon,

On 11/2/25 8:53 PM, Simon Glass wrote:
> Hi Quentin,
> 
> On Fri, 31 Oct 2025 at 16:23, Quentin Schulz <foss+uboot@0leil.net> wrote:
>>
>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>
>> mkimage has support for OpenSSL engines but binman currently doesn't for
>> direct callers of mkimage (e.g. the fit etype). This prepares for adding
>> support for OpenSSL engines for signing elements of a FIT image, which
>> will done in the next commit.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>> ---
>>   tools/binman/btool/mkimage.py | 5 ++++-
>>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> Please make sure this is tested.
> 

That was the anticipated and feared answer. I'll need to figure out how 
to create a dummy OpenSSL engine which doesn't require any hardware so 
it can be part of the CI. I have no experience with OpenSSL, so this 
will take a while.

Just to be sure I'm not sinking time into things U-Boot has no interest 
in, would supporting OpenSSL engines for signing be mergeable? OpenSSL 
has deprecated engines with their 3.0 release in favor of providers (see 
a recent series on the U-Boot ML for their support in U-Boot and 
https://github.com/openssl/openssl/blob/master/README-ENGINES.md for the 
official stance of OpenSSL on this). Porting my employer's engine to 
provider isn't planned (yet?) but I would like to know if U-Boot has no 
interest supporting that use-case, in which case I will "happily" keep 
this downstream only.

Thanks!
Quentin

Re: [PATCH 2/3] tools: binman: mkimage: add support for passing the engine

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]

On Mon, Nov 03, 2025 at 01:13:04PM +0100, Quentin Schulz wrote:
> Hi Simon,
> 
> On 11/2/25 8:53 PM, Simon Glass wrote:
> > Hi Quentin,
> > 
> > On Fri, 31 Oct 2025 at 16:23, Quentin Schulz <foss+uboot@0leil.net> wrote:
> > > 
> > > From: Quentin Schulz <quentin.schulz@cherry.de>
> > > 
> > > mkimage has support for OpenSSL engines but binman currently doesn't for
> > > direct callers of mkimage (e.g. the fit etype). This prepares for adding
> > > support for OpenSSL engines for signing elements of a FIT image, which
> > > will done in the next commit.
> > > 
> > > Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> > > ---
> > >   tools/binman/btool/mkimage.py | 5 ++++-
> > >   1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > Please make sure this is tested.
> > 
> 
> That was the anticipated and feared answer. I'll need to figure out how to
> create a dummy OpenSSL engine which doesn't require any hardware so it can
> be part of the CI. I have no experience with OpenSSL, so this will take a
> while.
> 
> Just to be sure I'm not sinking time into things U-Boot has no interest in,
> would supporting OpenSSL engines for signing be mergeable? OpenSSL has
> deprecated engines with their 3.0 release in favor of providers (see a
> recent series on the U-Boot ML for their support in U-Boot and
> https://github.com/openssl/openssl/blob/master/README-ENGINES.md for the
> official stance of OpenSSL on this). Porting my employer's engine to
> provider isn't planned (yet?) but I would like to know if U-Boot has no
> interest supporting that use-case, in which case I will "happily" keep this
> downstream only.

This is another case I think where the utility of adding a test is
important too. For the question of supporting SSL and engines, the
answer is that LibreSSL isn't doing what OpenSSL is doing and we will
continue supporting LibreSSL using hosts. And I would rather see this
code in the project, so that the real life needs can be accounted for in
future changes to the code than it be kept out because introducing a
dummy test wasn't easy and so didn't end up happening.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 2/3] tools: binman: mkimage: add support for passing the engine

[Quentin Schulz]

Hi Tom,

On 11/3/25 3:17 PM, Tom Rini wrote:
> On Mon, Nov 03, 2025 at 01:13:04PM +0100, Quentin Schulz wrote:
>> Hi Simon,
>>
>> On 11/2/25 8:53 PM, Simon Glass wrote:
>>> Hi Quentin,
>>>
>>> On Fri, 31 Oct 2025 at 16:23, Quentin Schulz <foss+uboot@0leil.net> wrote:
>>>>
>>>> From: Quentin Schulz <quentin.schulz@cherry.de>
>>>>
>>>> mkimage has support for OpenSSL engines but binman currently doesn't for
>>>> direct callers of mkimage (e.g. the fit etype). This prepares for adding
>>>> support for OpenSSL engines for signing elements of a FIT image, which
>>>> will done in the next commit.
>>>>
>>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
>>>> ---
>>>>    tools/binman/btool/mkimage.py | 5 ++++-
>>>>    1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> Please make sure this is tested.
>>>
>>
>> That was the anticipated and feared answer. I'll need to figure out how to
>> create a dummy OpenSSL engine which doesn't require any hardware so it can
>> be part of the CI. I have no experience with OpenSSL, so this will take a
>> while.
>>
>> Just to be sure I'm not sinking time into things U-Boot has no interest in,
>> would supporting OpenSSL engines for signing be mergeable? OpenSSL has
>> deprecated engines with their 3.0 release in favor of providers (see a
>> recent series on the U-Boot ML for their support in U-Boot and
>> https://github.com/openssl/openssl/blob/master/README-ENGINES.md for the
>> official stance of OpenSSL on this). Porting my employer's engine to
>> provider isn't planned (yet?) but I would like to know if U-Boot has no
>> interest supporting that use-case, in which case I will "happily" keep this
>> downstream only.
> 
> This is another case I think where the utility of adding a test is
> important too. For the question of supporting SSL and engines, the
> answer is that LibreSSL isn't doing what OpenSSL is doing and we will
> continue supporting LibreSSL using hosts. And I would rather see this
> code in the project, so that the real life needs can be accounted for in
> future changes to the code than it be kept out because introducing a
> dummy test wasn't easy and so didn't end up happening.
> 

I wanted to make sure the time I would spend on writing the tests 
wouldn't be lost on me if U-Boot had no interest in supporting signing 
with OpenSSL engines in the first place :)

I'll add this on my ever growing todo list and will send a v2 in the future.

Thanks for the quick feedback!

Cheers,
Quentin

Re: [PATCH 2/3] tools: binman: mkimage: add support for passing the engine

[Simon Glass]

Hi Quentin,

On Mon, 3 Nov 2025 at 13:13, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Simon,
>
> On 11/2/25 8:53 PM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Fri, 31 Oct 2025 at 16:23, Quentin Schulz <foss+uboot@0leil.net> wrote:
> >>
> >> From: Quentin Schulz <quentin.schulz@cherry.de>
> >>
> >> mkimage has support for OpenSSL engines but binman currently doesn't for
> >> direct callers of mkimage (e.g. the fit etype). This prepares for adding
> >> support for OpenSSL engines for signing elements of a FIT image, which
> >> will done in the next commit.
> >>
> >> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> >> ---
> >>   tools/binman/btool/mkimage.py | 5 ++++-
> >>   1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > Please make sure this is tested.
> >
>
> That was the anticipated and feared answer. I'll need to figure out how
> to create a dummy OpenSSL engine which doesn't require any hardware so
> it can be part of the CI. I have no experience with OpenSSL, so this
> will take a while.

You can actually just fake it in Binman, or even mock it. You don't
need to do things for real.

For example, see testFetchBintools() which uses mock.patch() to
provide a fake download. There is also command.TEST_RESULT which lets
you fake a command - e.g. testVblock() does this.

If you are worried about how to get real data so that the test will
pass, you can just plumb in some canned data for that purpose.

>
> Just to be sure I'm not sinking time into things U-Boot has no interest
> in, would supporting OpenSSL engines for signing be mergeable? OpenSSL
> has deprecated engines with their 3.0 release in favor of providers (see
> a recent series on the U-Boot ML for their support in U-Boot and
> https://github.com/openssl/openssl/blob/master/README-ENGINES.md for the
> official stance of OpenSSL on this). Porting my employer's engine to
> provider isn't planned (yet?) but I would like to know if U-Boot has no
> interest supporting that use-case, in which case I will "happily" keep
> this downstream only.

It seems very useful and interesting to me.

Regards,
Simon

Re: [PATCH 3/3] tools: binman: fit: add support for OpenSSL engines

[Peter Robinson]

Hey Quentin,

> This adds support for using an OpenSSL engine for signing a FIT image.
> To use it, one should set the fit,sign-engine property at the FIT node
> level with the engine to use. This will in turn call mkimage with the -N
> option.

Just to be aware this should likely be a OpenSSL provider, engines in
OpenSSL are deprecated and due to be removed in 4.0. A lot of distros
are already dropping support for engines. There's a patch [1] adding
support for Providers support to U-Boot, I suspect we shouldn't be
adding more deps on the Engine support. OpenSSL 4 is due in March.

[1] https://lists.denx.de/pipermail/u-boot/2025-October/601616.html
[2] https://openssl-library.org/roadmap/index.html

> The key-name-hint property in the signature node will be used verbatim
> as key_id in OpenSSL engine API.
>
> We could somehow still decide to pass some keys_dir to mkimage when
> signing with an engine is enabled (mkimage does support that!),
> unfortunately binman resolves key paths absolutely. I don't believe an
> OpenSSL engine will happen to have the exact same key_id than the path
> to the encryption key, so fit,encrypt and fit,sign-engine cannot
> cohabit.
>
> The public key (with .crt extension) is still required if it needs to be
> embedded in the SPL DTB for example.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
>  tools/binman/entries.rst  | 22 +++++++++++++++++++---
>  tools/binman/etype/fit.py | 41 +++++++++++++++++++++++++++++++++++++----
>  2 files changed, 56 insertions(+), 7 deletions(-)
>
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index 8922d6cd070..7b162a3edb8 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -885,9 +885,10 @@ The top-level 'fit' node supports the following special properties:
>
>      fit,sign
>          Enable signing FIT images via mkimage as described in
> -        verified-boot.rst. If the property is found, the private keys path
> -        is detected among binman include directories and passed to mkimage
> -        via  -k flag. All the keys required for signing FIT must be
> +        verified-boot.rst.
> +        If the property is found and fit,sign-engine is not set, the private
> +        keys path is detected among binman include directories and passed to
> +        mkimage via -k flag. All the keys required for signing FIT must be
>          available at time of signing and must be located in single include
>          directory.
>
> @@ -898,6 +899,21 @@ The top-level 'fit' node supports the following special properties:
>          required for encrypting the FIT must be available at the time of
>          encrypting and must be located in a single include directory.
>
> +        Incompatible with fit,sign-engine.
> +
> +    fit,sign-engine
> +        Indicates the OpenSSL engine to use for signing the FIT image. This
> +        is passed to mkimage via the `-N` flag. Example::
> +
> +            fit,sign-engine = "my-engine";
> +
> +        No `-k` argument will be passed to mkimage. The key_id passed to the
> +        OpenSSL engine API is the verbatim value of the key-name-hint property.
> +
> +        Depends on fit,sign.
> +
> +        Incompatible with fit,encrypt.
> +
>  Substitutions
>  ~~~~~~~~~~~~~
>
> diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
> index db40479d30e..df4cc9b749c 100644
> --- a/tools/binman/etype/fit.py
> +++ b/tools/binman/etype/fit.py
> @@ -104,9 +104,10 @@ class Entry_fit(Entry_section):
>
>          fit,sign
>              Enable signing FIT images via mkimage as described in
> -            verified-boot.rst. If the property is found, the private keys path
> -            is detected among binman include directories and passed to mkimage
> -            via  -k flag. All the keys required for signing FIT must be
> +            verified-boot.rst.
> +            If the property is found and fit,sign-engine is not set, the private
> +            keys path is detected among binman include directories and passed to
> +            mkimage via -k flag. All the keys required for signing FIT must be
>              available at time of signing and must be located in single include
>              directory.
>
> @@ -117,6 +118,21 @@ class Entry_fit(Entry_section):
>              required for encrypting the FIT must be available at the time of
>              encrypting and must be located in a single include directory.
>
> +            Incompatible with fit,sign-engine.
> +
> +        fit,sign-engine
> +            Indicates the OpenSSL engine to use for signing the FIT image. This
> +            is passed to mkimage via the `-N` flag. Example::
> +
> +                fit,sign-engine = "my-engine";
> +
> +            No `-k` argument will be passed to mkimage. The key_id passed to the
> +            OpenSSL engine API is the verbatim value of the key-name-hint property.
> +
> +            Depends on fit,sign.
> +
> +            Incompatible with fit,encrypt.
> +
>      Substitutions
>      ~~~~~~~~~~~~~
>
> @@ -620,7 +636,24 @@ class Entry_fit(Entry_section):
>              args.update({'align': fdt_util.fdt32_to_cpu(align.value)})
>          if (self._fit_props.get('fit,sign') is not None or
>              self._fit_props.get('fit,encrypt') is not None):
> -            args.update({'keys_dir': self._get_keys_dir(data)})
> +            engine = None
> +            if self._fit_props.get('fit,sign') is not None:
> +                engine_prop = self._fit_props.get('fit,sign-engine')
> +                if engine_prop is not None:
> +                    engine = engine_prop.value
> +                    args.update({'engine': engine})
> +            # Don't pass a key-dir to mkimage in case an engine is used to sign
> +            # as we don't need a private key on storage anyway.
> +            # Additionally, binman pass an absolute path as keys_dir which is
> +            # highly unlikely to actually make sense for engines.
> +            # Because of that limitation, we currently cannot support at the
> +            # same time fit,encrypt and fit,sign-engine.
> +            # mkimage will read key-name-hint and pass it verbatim to the engine
> +            # as key_id in the OpenSSL engine API instead.
> +            if engine is None:
> +                args.update({'keys_dir': self._get_keys_dir(data)})
> +            elif self._fit_props.get('fit,encrypt') is not None:
> +                self.Raise('Cannot have both fit,encrypt and fit,sign-engine')
>          if self.mkimage.run(reset_timestamp=True, output_fname=output_fname,
>                              **args) is None:
>              if not self.GetAllowMissing():
>
> --
> 2.51.0
>

Re: [PATCH 3/3] tools: binman: fit: add support for OpenSSL engines

[Quentin Schulz]

Hi Peter,

On 11/3/25 5:21 PM, Peter Robinson wrote:
> Hey Quentin,
> 
>> This adds support for using an OpenSSL engine for signing a FIT image.
>> To use it, one should set the fit,sign-engine property at the FIT node
>> level with the engine to use. This will in turn call mkimage with the -N
>> option.
> 
> Just to be aware this should likely be a OpenSSL provider, engines in
> OpenSSL are deprecated and due to be removed in 4.0. A lot of distros
> are already dropping support for engines. There's a patch [1] adding
> support for Providers support to U-Boot, I suspect we shouldn't be
> adding more deps on the Engine support. OpenSSL 4 is due in March.
> 

There is no plan (yet?) migrating my employer's engine to a provider, so 
I have no interest in doing that.

Additionally, Tom said[1] that LibreSSL isn't going the OpenSSL route so 
engines probably are here to stay?

Also, OpenSSL 3.5 (LTS) is supported until mid-2030.

Cheers,
Quentin

[1] 
https://lore.kernel.org/u-boot/20251031-binman-engine-v1-0-c13c1b5dac43@cherry.de/T/#m8002ea155864cf8d1ab2b8bb16b997089f4fac0e

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

[Wolfgang Wallner]

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.
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.

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.

Kind regards,
Wolfgang 

Re: [PATCH 1/3] fit: support signing with only an engine_id

[Wolfgang Wallner]

Hi Quentin,

From: Quentin Schulz <quentin.schulz@cherry.de>
> Currently, when one wants to use an OpenSSL engine to sign a FIT image,
> one needs to pass a keydir (via -k) to mkimage which will then be
> prepended to the value of the key-name-hint before being passed as
> key_id argument to the OpenSSL Engine API, or pass a keyfile (via -G) to
> mkimage.
> 
> My OpenSSL engine only has "slots" which are not mapped like
> directories, so using keydir is not proper, though I could simply have
> -k '' I guess but this won't work currently with binman anyway.
> 
> Additionally, passing a keyfile when using an engine doesn't make sense
> as the key is stored in the engine.
> 
> Let simply allow FIT images be signed if both keydir and keyfile are
> missing but an engine is to be used.
> 
> The keyname member is already filled by looking at key-name-hint
> property in the FIT and passed verbatim to the engine, which is exactly
> what is needed here.
> 
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
>  tools/fit_image.c  | 3 ++-
>  tools/image-host.c | 4 ++--
>  2 files changed, 4 insertions(+), 3 deletions(-)

Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>

Regards, Wolfgang

Re: [PATCH 2/3] tools: binman: mkimage: add support for passing the engine

[Wolfgang Wallner]

Hi Quentin,

From: Quentin Schulz <quentin.schulz@cherry.de>
> mkimage has support for OpenSSL engines but binman currently doesn't for
> direct callers of mkimage (e.g. the fit etype). This prepares for adding
> support for OpenSSL engines for signing elements of a FIT image, which
> will done in the next commit.
> 
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
>  tools/binman/btool/mkimage.py | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>

Regards, Wolfgang

Re: [PATCH 3/3] tools: binman: fit: add support for OpenSSL engines

[Wolfgang Wallner]

Hi Quentin,

From: Quentin Schulz <quentin.schulz@cherry.de>
> This adds support for using an OpenSSL engine for signing a FIT image.
> To use it, one should set the fit,sign-engine property at the FIT node
> level with the engine to use. This will in turn call mkimage with the -N
> option.
> 
> The key-name-hint property in the signature node will be used verbatim
> as key_id in OpenSSL engine API.
> 
> We could somehow still decide to pass some keys_dir to mkimage when
> signing with an engine is enabled (mkimage does support that!),
> unfortunately binman resolves key paths absolutely. I don't believe an
> OpenSSL engine will happen to have the exact same key_id than the path
> to the encryption key, so fit,encrypt and fit,sign-engine cannot
> cohabit.
> 
> The public key (with .crt extension) is still required if it needs to be
> embedded in the SPL DTB for example.
> 
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
>  tools/binman/entries.rst  | 22 +++++++++++++++++++---
>  tools/binman/etype/fit.py | 41 +++++++++++++++++++++++++++++++++++++----
>  2 files changed, 56 insertions(+), 7 deletions(-)

Reviewed-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>
Tested-by: Wolfgang Wallner <wolfgang.wallner@br-automation.com>

Test case: Signed FIT image with U-Boot Proper booted from SPL
           sha256,rsa2048, openSSL with a PKCS11 library using the engine API
           fit,sign-engine = "pkcs11";
           key-name-hint = "pkcs11:<pkcs11-id>

Regards, Wolfgang

Re: [PATCH 3/3] tools: binman: fit: add support for OpenSSL engines

[Wolfgang Wallner]

Hi Peter,
           
> > This adds support for using an OpenSSL engine for signing a FIT image.
> > To use it, one should set the fit,sign-engine property at the FIT node
> > level with the engine to use. This will in turn call mkimage with the -N
> > option.
> 
> Just to be aware this should likely be a OpenSSL provider, engines in
> OpenSSL are deprecated and due to be removed in 4.0. A lot of distros
> are already dropping support for engines. There's a patch [1] adding
> support for Providers support to U-Boot, I suspect we shouldn't be
> adding more deps on the Engine support. OpenSSL 4 is due in March.
         
I'm aware that the engine API is deprecated in OpenSSL, and that the provider
API is the way to go forward.

But the PKI provider of my employer currently only provides a PKCS#11 library
with an engine API, and I'm not aware of any plans yet if/when they will
be supporting the provider API.

So for the transition period it would be nice to keep the engine API around as
such use cases still depend on it.

Kind regards, Wolfgang

Re: [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

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

[Wolfgang Wallner]

 Hi Quentin,

> 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://urldefense.com/v3/__https://elixir.bootlin.com/u-boot/v2025.10/source/lib/rsa/rsa-sign.c*L677__;Iw!!NLW3fF9v!NY3fN9fyh10vF5rVo7-QzKVDnswgoETJaGRb-wCmd8mCjtUXscKGXP7DjqRDJt79NEjixr6ATvMFWfY0vppIHVJNggm5SpqGOpnVHenp$

Yes, that is the line that includes the value of key-name-hint into the node
name.

> 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://urldefense.com/v3/__https://elixir.bootlin.com/u-boot/v2025.10/source/boot/image-fit-sig.c*L87__;Iw!!NLW3fF9v!NY3fN9fyh10vF5rVo7-QzKVDnswgoETJaGRb-wCmd8mCjtUXscKGXP7DjqRDJt79NEjixr6ATvMFWfY0vppIHVJNggm5SpqGOopSJNvU$
> and/or
> https://urldefense.com/v3/__https://elixir.bootlin.com/u-boot/v2025.10/source/lib/rsa/rsa-verify.c*L538__;Iw!!NLW3fF9v!NY3fN9fyh10vF5rVo7-QzKVDnswgoETJaGRb-wCmd8mCjtUXscKGXP7DjqRDJt79NEjixr6ATvMFWfY0vppIHVJNggm5SpqGOr9w2Pt_$ .

For me this make sense, but Security is not my main area, it would be good to
get more feedback from the U-Boot community on such an approach.

> > 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?

Yes. But I'm not sure what exactly you are asking for.
Please tell me what you are interested in, and I will provide it.

> 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.

With the workaround I use (full key-name-hint for U-Boot FIT, but simple
key-name-hint for SPL) the search for a key in rsa_verify_hash() will fail
at first, and then the loop iterates over all keys (in my current test case
the is just key), and the verification then works with the one key that is
found.

> 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?

Yes, exactly.

mkimage would support to pass in this information via the key-directory
parameter (-k or --key-dir). But this has two drawbacks:

1) It feels like a hack to pass key information via a parameter that is
supposed to be a directory
2) It is currently not implemented in binman.
 
> 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.

Yes, I think that would make sense.

How about the following?
   key-name-hint      for a short human readable name
   key-specification  for a full description for which key to use
   
In my case 'key-specification' would then be the long PKCS#11-string which
uniquely identifies the key within the PKI.

It might make sense to also add such a parameter to mkimage, as it does not
really fit the description of a key directory as mentioned above, even if it
works in the current implementation.

> > 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.

Is this behavior specific for the rockchip code, or in the generic part?

> 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.

How would it work with environment variables?
There could be multiple signature nodes with different key-name-hints in a
FIT description, would you then assume to have different environment variables
for each?

> 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).

regards, Wolfgang

Re: [PATCH 3/3] tools: binman: fit: add support for OpenSSL engines

[Peter Robinson]

On Tue, 11 Nov 2025 at 10:14, Wolfgang Wallner
<wolfgang.wallner@br-automation.com> wrote:
>
> Hi Peter,
>
> > > This adds support for using an OpenSSL engine for signing a FIT image.
> > > To use it, one should set the fit,sign-engine property at the FIT node
> > > level with the engine to use. This will in turn call mkimage with the -N
> > > option.
> >
> > Just to be aware this should likely be a OpenSSL provider, engines in
> > OpenSSL are deprecated and due to be removed in 4.0. A lot of distros
> > are already dropping support for engines. There's a patch [1] adding
> > support for Providers support to U-Boot, I suspect we shouldn't be
> > adding more deps on the Engine support. OpenSSL 4 is due in March.
>
> I'm aware that the engine API is deprecated in OpenSSL, and that the provider
> API is the way to go forward.
>
> But the PKI provider of my employer currently only provides a PKCS#11 library
> with an engine API, and I'm not aware of any plans yet if/when they will
> be supporting the provider API.
>
> So for the transition period it would be nice to keep the engine API around as
> such use cases still depend on it.

my comment wasn't so much about removing engine support but rather
having parity with the newer version so that when users upgrade they
don't end up being stuck with broken functionality.

Re: [PATCH 3/3] tools: binman: fit: add support for OpenSSL engines

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

On Mon, Nov 17, 2025 at 03:18:08PM +0000, Peter Robinson wrote:
> On Tue, 11 Nov 2025 at 10:14, Wolfgang Wallner
> <wolfgang.wallner@br-automation.com> wrote:
> >
> > Hi Peter,
> >
> > > > This adds support for using an OpenSSL engine for signing a FIT image.
> > > > To use it, one should set the fit,sign-engine property at the FIT node
> > > > level with the engine to use. This will in turn call mkimage with the -N
> > > > option.
> > >
> > > Just to be aware this should likely be a OpenSSL provider, engines in
> > > OpenSSL are deprecated and due to be removed in 4.0. A lot of distros
> > > are already dropping support for engines. There's a patch [1] adding
> > > support for Providers support to U-Boot, I suspect we shouldn't be
> > > adding more deps on the Engine support. OpenSSL 4 is due in March.
> >
> > I'm aware that the engine API is deprecated in OpenSSL, and that the provider
> > API is the way to go forward.
> >
> > But the PKI provider of my employer currently only provides a PKCS#11 library
> > with an engine API, and I'm not aware of any plans yet if/when they will
> > be supporting the provider API.
> >
> > So for the transition period it would be nice to keep the engine API around as
> > such use cases still depend on it.
> 
> my comment wasn't so much about removing engine support but rather
> having parity with the newer version so that when users upgrade they
> don't end up being stuck with broken functionality.

Yes and I think an unfortunate part of the problem here is that it seems
like the hardware signing vendors haven't committed to a strategy yet as
it's multiple reports of "my vendor has no plans yet". So we'll need to
have plans to support both for some time is all.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 3/3] tools: binman: fit: add support for OpenSSL engines

[Quentin Schulz]

Hi Tom, Peter, Wolfgang,

On 11/17/25 4:38 PM, Tom Rini wrote:
> On Mon, Nov 17, 2025 at 03:18:08PM +0000, Peter Robinson wrote:
>> On Tue, 11 Nov 2025 at 10:14, Wolfgang Wallner
>> <wolfgang.wallner@br-automation.com> wrote:
>>>
>>> Hi Peter,
>>>
>>>>> This adds support for using an OpenSSL engine for signing a FIT image.
>>>>> To use it, one should set the fit,sign-engine property at the FIT node
>>>>> level with the engine to use. This will in turn call mkimage with the -N
>>>>> option.
>>>>
>>>> Just to be aware this should likely be a OpenSSL provider, engines in
>>>> OpenSSL are deprecated and due to be removed in 4.0. A lot of distros
>>>> are already dropping support for engines. There's a patch [1] adding
>>>> support for Providers support to U-Boot, I suspect we shouldn't be
>>>> adding more deps on the Engine support. OpenSSL 4 is due in March.
>>>
>>> I'm aware that the engine API is deprecated in OpenSSL, and that the provider
>>> API is the way to go forward.
>>>
>>> But the PKI provider of my employer currently only provides a PKCS#11 library
>>> with an engine API, and I'm not aware of any plans yet if/when they will
>>> be supporting the provider API.
>>>
>>> So for the transition period it would be nice to keep the engine API around as
>>> such use cases still depend on it.
>>
>> my comment wasn't so much about removing engine support but rather
>> having parity with the newer version so that when users upgrade they
>> don't end up being stuck with broken functionality.
> 
> Yes and I think an unfortunate part of the problem here is that it seems
> like the hardware signing vendors haven't committed to a strategy yet as
> it's multiple reports of "my vendor has no plans yet". So we'll need to
> have plans to support both for some time is all.
> 

And considering 3.5 release that still supports engines is LTS until 
2030, there's sadly still time before the end of the world for those 
vendors :)

I also checked LibreSSL and they got rid of engines and do not support 
providers as far as I could tell (which is extrapolated from a grep 
through the code base). I do not know the reason. The API still exists 
but does nothing (or errors out). c.f. 
https://github.com/libressl/portable/blob/000396d2014eb8e961b674000365f0d4e1385022/ChangeLog#L527-L529

Newer OpenSSL (>=3.0.0 as far as I could tell) allow to use engines via 
the provider API (at least through CLI) by prefixing the engine with 
org.openssl.engine: when passed as "provider" to OpenSSL.

Ideally, what I'm trying to add could be reused verbatim with providers 
as well. But I'll need help here because I don't have any actual 
provider I could test my code against (except softhsm2 for pkcs11 I 
guess, which provides both provider and engines), as opposed to engines 
which we use in prod.

I've managed to develop what I believe to be a simple RSA engine to test 
FIT signing with it, as well as PKCS11 with SoftHSMv2. I have no 
security or crypto background so I have no idea if what I'm doing is 
proper or not except that it signs properly. I'm finalizing the patches 
for the v2 and will Cc the person who posted patches for supporting 
OpenSSL providers.

Cheers,
Quentin