[PATCH v2] Add support for OpenSSL Provider API

[PATCH v2] Add support for OpenSSL Provider API

[Eddie Kovsky]

The Engine API has been deprecated since the release of OpenSSL 3.0. End
users have been advised to migrate to the new Provider interface.
Several distributions have already removed support for engines, which is
preventing U-Boot from being compiled in those environments.

The Kconfig option OPENSSL_NO_DEPRECATED introduces support for the
Provider API while continuing to use the existing Engine API on distros
shipping older releases of OpenSSL.

This is based on similar work contributed by Jan Stancek updating Linux
to use the Provider interface.

    commit 558bdc45dfb2669e1741384a0c80be9c82fa052c
    Author: Jan Stancek <jstancek@redhat.com>
    Date:   Fri Sep 20 19:52:48 2024 +0300

        sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3

The changes have been tested with the FIT signature verification vboot
tests on Fedora 42 and Debian 13. All 30 tests pass with both the legacy
Engine library installed and with the Provider API.

Signed-off-by: Eddie Kovsky <ekovsky@redhat.com>
---
Changes in v2:
  - Remove default for new Kconfig option
  - Use #ifdef instead of IS_ENABLED macro
  - Remove comment after #endif
  - Remove unrelated checkpatch cleanup of 'sslErr' variable name
v1: https://lore.kernel.org/u-boot/20251017171329.255689-1-ekovsky@redhat.com/
---
 lib/aes/aes-encrypt.c |  2 +
 lib/rsa/Kconfig       |  7 ++++
 lib/rsa/rsa-sign.c    | 89 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 98 insertions(+)

diff --git a/lib/aes/aes-encrypt.c b/lib/aes/aes-encrypt.c
index 90e1407b4f09..9595772cf58b 100644
--- a/lib/aes/aes-encrypt.c
+++ b/lib/aes/aes-encrypt.c
@@ -16,7 +16,9 @@
 #include <openssl/err.h>
 #include <openssl/ssl.h>
 #include <openssl/evp.h>
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 #include <openssl/engine.h>
+#endif
 #include <uboot_aes.h>
 
 #if OPENSSL_VERSION_NUMBER >= 0x10000000L
diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
index 9033384e60a3..1bf0ac96d598 100644
--- a/lib/rsa/Kconfig
+++ b/lib/rsa/Kconfig
@@ -20,6 +20,13 @@ config SPL_RSA
 	bool "Use RSA Library within SPL"
 	depends on SPL
 
+config OPENSSL_NO_DEPRECATED
+	bool "Build U-Boot without support for OpenSSL Engine"
+	help
+	  Add support for the OpenSSL Provider API, which is the officially
+	  supported mechanism in OpenSSL 3.x and later releases for accessing
+	  hardware and software cryptography.
+
 config SPL_RSA_VERIFY
 	bool
 	depends on SPL_RSA
diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index 92b9d7876e52..1e874de6ba98 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -19,7 +19,43 @@
 #include <openssl/err.h>
 #include <openssl/ssl.h>
 #include <openssl/evp.h>
+#ifdef CONFIG_OPENSSL_NO_DEPRECATED
+#include <err.h>
+#include <openssl/provider.h>
+#include <openssl/store.h>
+#else
 #include <openssl/engine.h>
+#endif
+
+#ifdef CONFIG_OPENSSL_NO_DEPRECATED
+#define ERR(cond, fmt, ...)				\
+	do {						\
+		bool __cond = (cond);			\
+		drain_openssl_errors(__LINE__, 0);	\
+		if (__cond) {				\
+			errx(1, fmt, ## __VA_ARGS__);	\
+		}					\
+	} while (0)
+
+static void drain_openssl_errors(int l, int silent)
+{
+	const char *file;
+	char buf[120];
+	int e, line;
+
+	if (ERR_peek_error() == 0)
+		return;
+	if (!silent)
+		fprintf(stderr, "At main.c:%d:\n", l);
+
+	while ((e = ERR_peek_error_line(&file, &line))) {
+		ERR_error_string(e, buf);
+		if (!silent)
+			fprintf(stderr, "- SSL %s: %s:%d\n", buf, file, line);
+		ERR_get_error();
+	}
+}
+#endif
 
 static int rsa_err(const char *msg)
 {
@@ -98,6 +134,7 @@ err_cert:
  * @evpp	Returns EVP_PKEY object, or NULL on failure
  * Return: 0 if ok, -ve on error (in which case *evpp will be set to NULL)
  */
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 static int rsa_engine_get_pub_key(const char *keydir, const char *name,
 				  ENGINE *engine, EVP_PKEY **evpp)
 {
@@ -157,6 +194,7 @@ static int rsa_engine_get_pub_key(const char *keydir, const char *name,
 
 	return 0;
 }
+#endif
 
 /**
  * rsa_get_pub_key() - read a public key
@@ -170,8 +208,10 @@ static int rsa_engine_get_pub_key(const char *keydir, const char *name,
 static int rsa_get_pub_key(const char *keydir, const char *name,
 			   ENGINE *engine, EVP_PKEY **evpp)
 {
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 	if (engine)
 		return rsa_engine_get_pub_key(keydir, name, engine, evpp);
+#endif
 	return rsa_pem_get_pub_key(keydir, name, evpp);
 }
 
@@ -207,6 +247,37 @@ static int rsa_pem_get_priv_key(const char *keydir, const char *name,
 		return -ENOENT;
 	}
 
+#ifdef CONFIG_OPENSSL_NO_DEPRECATED
+	EVP_PKEY *private_key = NULL;
+	OSSL_STORE_CTX *store;
+
+	if (!OSSL_PROVIDER_try_load(NULL, "pkcs11", true))
+		ERR(1, "OSSL_PROVIDER_try_load(pkcs11)");
+	if (!OSSL_PROVIDER_try_load(NULL, "default", true))
+		ERR(1, "OSSL_PROVIDER_try_load(default)");
+
+	store = OSSL_STORE_open(path, NULL, NULL, NULL, NULL);
+	ERR(!store, "OSSL_STORE_open");
+
+	while (!OSSL_STORE_eof(store)) {
+		OSSL_STORE_INFO *info = OSSL_STORE_load(store);
+
+		if (!info) {
+			drain_openssl_errors(__LINE__, 0);
+			continue;
+		}
+		if (OSSL_STORE_INFO_get_type(info) == OSSL_STORE_INFO_PKEY) {
+			private_key = OSSL_STORE_INFO_get1_PKEY(info);
+			ERR(!private_key, "OSSL_STORE_INFO_get1_PKEY");
+		}
+		OSSL_STORE_INFO_free(info);
+		if (private_key)
+			break;
+	}
+	OSSL_STORE_close(store);
+
+	*evpp = private_key;
+#else
 	if (!PEM_read_PrivateKey(f, evpp, NULL, path)) {
 		rsa_err("Failure reading private key");
 		fclose(f);
@@ -214,6 +285,7 @@ static int rsa_pem_get_priv_key(const char *keydir, const char *name,
 	}
 	fclose(f);
 
+#endif
 	return 0;
 }
 
@@ -226,6 +298,7 @@ static int rsa_pem_get_priv_key(const char *keydir, const char *name,
  * @evpp	Returns EVP_PKEY object, or NULL on failure
  * Return: 0 if ok, -ve on error (in which case *evpp will be set to NULL)
  */
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 static int rsa_engine_get_priv_key(const char *keydir, const char *name,
 				   const char *keyfile,
 				   ENGINE *engine, EVP_PKEY **evpp)
@@ -293,6 +366,7 @@ static int rsa_engine_get_priv_key(const char *keydir, const char *name,
 
 	return 0;
 }
+#endif
 
 /**
  * rsa_get_priv_key() - read a private key
@@ -306,9 +380,11 @@ static int rsa_engine_get_priv_key(const char *keydir, const char *name,
 static int rsa_get_priv_key(const char *keydir, const char *name,
 			    const char *keyfile, ENGINE *engine, EVP_PKEY **evpp)
 {
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 	if (engine)
 		return rsa_engine_get_priv_key(keydir, name, keyfile, engine,
 					       evpp);
+#endif
 	return rsa_pem_get_priv_key(keydir, name, keyfile, evpp);
 }
 
@@ -325,6 +401,7 @@ static int rsa_init(void)
 	return 0;
 }
 
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 static int rsa_engine_init(const char *engine_id, ENGINE **pe)
 {
 	const char *key_pass;
@@ -380,6 +457,7 @@ static void rsa_engine_remove(ENGINE *e)
 		ENGINE_free(e);
 	}
 }
+#endif
 
 static int rsa_sign_with_key(EVP_PKEY *pkey, struct padding_algo *padding_algo,
 			     struct checksum_algo *checksum_algo,
@@ -480,11 +558,13 @@ int rsa_sign(struct image_sign_info *info,
 	if (ret)
 		return ret;
 
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 	if (info->engine_id) {
 		ret = rsa_engine_init(info->engine_id, &e);
 		if (ret)
 			return ret;
 	}
+#endif
 
 	ret = rsa_get_priv_key(info->keydir, info->keyname, info->keyfile,
 			       e, &pkey);
@@ -496,16 +576,21 @@ int rsa_sign(struct image_sign_info *info,
 		goto err_sign;
 
 	EVP_PKEY_free(pkey);
+
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 	if (info->engine_id)
 		rsa_engine_remove(e);
+#endif
 
 	return ret;
 
 err_sign:
 	EVP_PKEY_free(pkey);
 err_priv:
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 	if (info->engine_id)
 		rsa_engine_remove(e);
+#endif
 	return ret;
 }
 
@@ -645,11 +730,13 @@ int rsa_add_verify_data(struct image_sign_info *info, void *keydest)
 	ENGINE *e = NULL;
 
 	debug("%s: Getting verification data\n", __func__);
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 	if (info->engine_id) {
 		ret = rsa_engine_init(info->engine_id, &e);
 		if (ret)
 			return ret;
 	}
+#endif
 	ret = rsa_get_pub_key(info->keydir, info->keyname, e, &pkey);
 	if (ret)
 		goto err_get_pub_key;
@@ -726,8 +813,10 @@ done:
 err_get_params:
 	EVP_PKEY_free(pkey);
 err_get_pub_key:
+#ifndef CONFIG_OPENSSL_NO_DEPRECATED
 	if (info->engine_id)
 		rsa_engine_remove(e);
+#endif
 
 	if (ret)
 		return ret;
-- 
2.51.0

Re: [PATCH v2] Add support for OpenSSL Provider API

[Quentin Schulz]

Hi Eddie,

On 10/27/25 8:58 PM, Eddie Kovsky wrote:
> [You don't often get email from ekovsky@redhat.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> The Engine API has been deprecated since the release of OpenSSL 3.0. End
> users have been advised to migrate to the new Provider interface.
> Several distributions have already removed support for engines, which is
> preventing U-Boot from being compiled in those environments.
> 

Which ones? How do I reproduce?

> The Kconfig option OPENSSL_NO_DEPRECATED introduces support for the

Please consider renaming this, OpenSSL itself uses OPENSSL_NO_DEPRECATED 
constants for many things. I would recommend simply renaming to 
OPENSSL_NO_ENGINE which is also the symbol OpenSSL is using. If there 
comes a time we have more OPENSSL_NO_ options, we can always have a 
"virtual" symbol called OPENSSL_NO_DEPRECATED which would select them 
all if one wanted for example.

> Provider API while continuing to use the existing Engine API on distros
> shipping older releases of OpenSSL.
> 

One can use org.openssl.engine: as prefix for provider arguments when 
one wants to use an engine still.

> This is based on similar work contributed by Jan Stancek updating Linux
> to use the Provider interface.
> 
>      commit 558bdc45dfb2669e1741384a0c80be9c82fa052c
>      Author: Jan Stancek <jstancek@redhat.com>
>      Date:   Fri Sep 20 19:52:48 2024 +0300
> 
>          sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3
> 
> The changes have been tested with the FIT signature verification vboot
> tests on Fedora 42 and Debian 13. All 30 tests pass with both the legacy
> Engine library installed and with the Provider API.
> 

Are there actually tests using an OpenSSL engine? Because otherwise it's 
simply checking that local keys are still working... which isn't that 
much different from what we currently have with engines when not using 
engines.

I'm implementing FIT images signing with OpenSSL engines, and it'd be 
nice if we could have something that doesn't require changes to support 
providers (or if it does, not in a confusing manner for example).

https://lore.kernel.org/u-boot/20251031-binman-engine-v1-0-c13c1b5dac43@cherry.de/T/#t 
for the v1, I'll soon (next hours or tomorrow) post a v2 and Cc you if 
you don't mind.

[...]

> diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
> index 9033384e60a3..1bf0ac96d598 100644
> --- a/lib/rsa/Kconfig
> +++ b/lib/rsa/Kconfig
> @@ -20,6 +20,13 @@ config SPL_RSA
>          bool "Use RSA Library within SPL"
>          depends on SPL
> 
> +config OPENSSL_NO_DEPRECATED
> +       bool "Build U-Boot without support for OpenSSL Engine"
> +       help
> +         Add support for the OpenSSL Provider API, which is the officially
> +         supported mechanism in OpenSSL 3.x and later releases for accessing
> +         hardware and software cryptography.
> +

mmmm Cannot we use providers for something else than RSA? In which case 
it's a bit odd to have it in lib/rsa/Kconfig (but I have no better 
suggestion).

>   config SPL_RSA_VERIFY
>          bool
>          depends on SPL_RSA

[...]

> @@ -207,6 +247,37 @@ static int rsa_pem_get_priv_key(const char *keydir, const char *name,
>                  return -ENOENT;
>          }
> 
> +#ifdef CONFIG_OPENSSL_NO_DEPRECATED
> +       EVP_PKEY *private_key = NULL;
> +       OSSL_STORE_CTX *store;
> +
> +       if (!OSSL_PROVIDER_try_load(NULL, "pkcs11", true))
> +               ERR(1, "OSSL_PROVIDER_try_load(pkcs11)");
> +       if (!OSSL_PROVIDER_try_load(NULL, "default", true))
> +               ERR(1, "OSSL_PROVIDER_try_load(default)");
> +
> +       store = OSSL_STORE_open(path, NULL, NULL, NULL, NULL);
> +       ERR(!store, "OSSL_STORE_open");
> +
> +       while (!OSSL_STORE_eof(store)) {
> +               OSSL_STORE_INFO *info = OSSL_STORE_load(store);
> +
> +               if (!info) {
> +                       drain_openssl_errors(__LINE__, 0);
> +                       continue;
> +               }
> +               if (OSSL_STORE_INFO_get_type(info) == OSSL_STORE_INFO_PKEY) {
> +                       private_key = OSSL_STORE_INFO_get1_PKEY(info);
> +                       ERR(!private_key, "OSSL_STORE_INFO_get1_PKEY");
> +               }
> +               OSSL_STORE_INFO_free(info);
> +               if (private_key)
> +                       break;
> +       }
> +       OSSL_STORE_close(store);
> +
> +       *evpp = private_key;
> +#else

Wondering if it really makes sense to have the provider API implemented 
as an #ifdef to save like 10 common lines between key-based and 
provider-based implems.

On another topic, my first reading of the code makes me a bit worried by 
the fact that there's seemingly no way to select whether we want to use 
a local key or a provider key. Also, I see "pkcs11" and "default" here, 
but how do I select which provider I want to use (e.g. my custom one). 
If I somehow manage to have a key named the same locally and in one or 
more providers, how do I make sure the proper one is selected? I'm 
wondering whether we should be reusing the engine parameter to select a 
provider?

I have 0 security or crypto background, don't hesitate to be verbose in 
your answer.

Cheers,
Quentin

Re: [PATCH v2] Add support for OpenSSL Provider API

[Eddie Kovsky]

Hi Quentin

On 11/17/25, Quentin Schulz wrote:
> Hi Eddie,
> 
> On 10/27/25 8:58 PM, Eddie Kovsky wrote:
> > [You don't often get email from ekovsky@redhat.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > The Engine API has been deprecated since the release of OpenSSL 3.0. End
> > users have been advised to migrate to the new Provider interface.
> > Several distributions have already removed support for engines, which is
> > preventing U-Boot from being compiled in those environments.
> > 
> 
> Which ones? How do I reproduce?
> 

As you are probably aware, OpenSSL deprecated the Engine API with the
3.0 release, and engines are likely to be removed entirely when
OpenSSL 4.0 is released in 2026. [1][2]

[1] https://docs.openssl.org/3.0/man7/migration_guide/#engines-and-method-apis
[2] https://github.com/openssl/openssl/discussions/21832

I don't have a comprehensive list of all distros. Fedora, RHEL 10,
Arch, and Debian 13 are all shipping OpenSSL 3.5. If you try to build
U-Boot in those environments the compiler will not be able to resolve the
engine API symbols and the build will fail.

Fedora is currently providing a bridge package openssl-devel-engine [3] to
help make the API transition easier, but that is only a temporary
solution. (I think Debian is currently doing something similar.)

[3] https://packages.fedoraproject.org/pkgs/openssl/openssl-devel-engine/

> > The Kconfig option OPENSSL_NO_DEPRECATED introduces support for the
> 
> Please consider renaming this, OpenSSL itself uses OPENSSL_NO_DEPRECATED
> constants for many things. I would recommend simply renaming to
> OPENSSL_NO_ENGINE which is also the symbol OpenSSL is using. If there comes
> a time we have more OPENSSL_NO_ options, we can always have a "virtual"
> symbol called OPENSSL_NO_DEPRECATED which would select them all if one
> wanted for example.
> 

I did give some thought to using a different name because I don't
like the double negative that comes from this construct:

    #ifndef CONFIG_OPENSSL_NO_DEPRECATED

But I kept it because the name is advantageous precisely because it's
already recognized by the OpenSSL API. OPENSSL_NO_DEPRECATED is a
user-defined macro.[4] When combined with the OPENSSL_API_COMPAT macro,
which is already defined in lib/rsa/rsa-sign.c, we can ensure that
deprecated symbols won't be available in sections where
OPENSSL_NO_DEPRECATED is defined.

[4] https://docs.openssl.org/3.0/man7/openssl_user_macros/

> > Provider API while continuing to use the existing Engine API on distros
> > shipping older releases of OpenSSL.
> > 
> 
> One can use org.openssl.engine: as prefix for provider arguments when one
> wants to use an engine still.
> 

Sorry, but it's not clear what you are referring to here.

> > This is based on similar work contributed by Jan Stancek updating Linux
> > to use the Provider interface.
> > 
> >      commit 558bdc45dfb2669e1741384a0c80be9c82fa052c
> >      Author: Jan Stancek <jstancek@redhat.com>
> >      Date:   Fri Sep 20 19:52:48 2024 +0300
> > 
> >          sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3
> > 
> > The changes have been tested with the FIT signature verification vboot
> > tests on Fedora 42 and Debian 13. All 30 tests pass with both the legacy
> > Engine library installed and with the Provider API.
> > 
> 
> Are there actually tests using an OpenSSL engine? Because otherwise it's
> simply checking that local keys are still working... which isn't that much
> different from what we currently have with engines when not using engines.
> 
> I'm implementing FIT images signing with OpenSSL engines, and it'd be nice
> if we could have something that doesn't require changes to support providers
> (or if it does, not in a confusing manner for example).
> 
> https://lore.kernel.org/u-boot/20251031-binman-engine-v1-0-c13c1b5dac43@cherry.de/T/#t
> for the v1, I'll soon (next hours or tomorrow) post a v2 and Cc you if you
> don't mind.
> 
> [...]
> 

As mentioned above, the motivation for this patch is that the Engine
API has already been deprecated. Projects that depend on OpenSSL will
need to move to the new Provider API in order to continue to function.

The FIT Signature Verification tests I used to exercise both APIs are
documented here.[5]

[5] https://docs.u-boot.org/en/latest/usage/fit/signature.html#u-boot-fit-signature-verification


> > diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
> > index 9033384e60a3..1bf0ac96d598 100644
> > --- a/lib/rsa/Kconfig
> > +++ b/lib/rsa/Kconfig
> > @@ -20,6 +20,13 @@ config SPL_RSA
> >          bool "Use RSA Library within SPL"
> >          depends on SPL
> > 
> > +config OPENSSL_NO_DEPRECATED
> > +       bool "Build U-Boot without support for OpenSSL Engine"
> > +       help
> > +         Add support for the OpenSSL Provider API, which is the officially
> > +         supported mechanism in OpenSSL 3.x and later releases for accessing
> > +         hardware and software cryptography.
> > +
> 
> mmmm Cannot we use providers for something else than RSA? In which case it's
> a bit odd to have it in lib/rsa/Kconfig (but I have no better suggestion).
> 

To the best of my knowledge, the only areas in the U-Boot source that
are using the Engine API are the RSA and AES libraries. All other uses
in U-Boot are clients of these two libraries.

> >   config SPL_RSA_VERIFY
> >          bool
> >          depends on SPL_RSA
> 
> [...]
> 
> > @@ -207,6 +247,37 @@ static int rsa_pem_get_priv_key(const char *keydir, const char *name,
> >                  return -ENOENT;
> >          }
> > 
> > +#ifdef CONFIG_OPENSSL_NO_DEPRECATED
> > +       EVP_PKEY *private_key = NULL;
> > +       OSSL_STORE_CTX *store;
> > +
> > +       if (!OSSL_PROVIDER_try_load(NULL, "pkcs11", true))
> > +               ERR(1, "OSSL_PROVIDER_try_load(pkcs11)");
> > +       if (!OSSL_PROVIDER_try_load(NULL, "default", true))
> > +               ERR(1, "OSSL_PROVIDER_try_load(default)");
> > +
> > +       store = OSSL_STORE_open(path, NULL, NULL, NULL, NULL);
> > +       ERR(!store, "OSSL_STORE_open");
> > +
> > +       while (!OSSL_STORE_eof(store)) {
> > +               OSSL_STORE_INFO *info = OSSL_STORE_load(store);
> > +
> > +               if (!info) {
> > +                       drain_openssl_errors(__LINE__, 0);
> > +                       continue;
> > +               }
> > +               if (OSSL_STORE_INFO_get_type(info) == OSSL_STORE_INFO_PKEY) {
> > +                       private_key = OSSL_STORE_INFO_get1_PKEY(info);
> > +                       ERR(!private_key, "OSSL_STORE_INFO_get1_PKEY");
> > +               }
> > +               OSSL_STORE_INFO_free(info);
> > +               if (private_key)
> > +                       break;
> > +       }
> > +       OSSL_STORE_close(store);
> > +
> > +       *evpp = private_key;
> > +#else
> 
> Wondering if it really makes sense to have the provider API implemented as
> an #ifdef to save like 10 common lines between key-based and provider-based
> implems.
> 
> On another topic, my first reading of the code makes me a bit worried by the
> fact that there's seemingly no way to select whether we want to use a local
> key or a provider key. Also, I see "pkcs11" and "default" here, but how do I
> select which provider I want to use (e.g. my custom one). If I somehow
> manage to have a key named the same locally and in one or more providers,
> how do I make sure the proper one is selected? I'm wondering whether we
> should be reusing the engine parameter to select a provider?
> 
> I have 0 security or crypto background, don't hesitate to be verbose in your
> answer.
> 
> Cheers,
> Quentin
> 

It's not the prettiest code. But I'm trying to be very conservative
in making these changes so that no one's workflow is disrupted.
Developers should be able to build U-Boot with the latest OpenSSL
without impacting developers who are in environments utilizing the
Engine API. The goal here is to preserve feature parity between the two
APIs. Adding support for custom Providers is outside the scope of this
change, but could certainly be added later.

Eddie

Re: [PATCH v2] Add support for OpenSSL Provider API

[Mattijs Korpershoek]

Hi Eddie,

Thank you for working on this. It would be really nice if we could build
U-Boot on more recent Linux distros without bridge packages such as
openssl-devel-engine.

On Fri, Nov 21, 2025 at 11:16, Eddie Kovsky <ekovsky@redhat.com> wrote:

> Hi Quentin
>
> On 11/17/25, Quentin Schulz wrote:
>> Hi Eddie,
>> 
>> On 10/27/25 8:58 PM, Eddie Kovsky wrote:
>> > [You don't often get email from ekovsky@redhat.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>> > 
>> > The Engine API has been deprecated since the release of OpenSSL 3.0. End
>> > users have been advised to migrate to the new Provider interface.
>> > Several distributions have already removed support for engines, which is
>> > preventing U-Boot from being compiled in those environments.
>> > 
>> 
>> Which ones? How do I reproduce?
>> 
>
> As you are probably aware, OpenSSL deprecated the Engine API with the
> 3.0 release, and engines are likely to be removed entirely when
> OpenSSL 4.0 is released in 2026. [1][2]
>
> [1] https://docs.openssl.org/3.0/man7/migration_guide/#engines-and-method-apis
> [2] https://github.com/openssl/openssl/discussions/21832
>
> I don't have a comprehensive list of all distros. Fedora, RHEL 10,
> Arch, and Debian 13 are all shipping OpenSSL 3.5. If you try to build
> U-Boot in those environments the compiler will not be able to resolve the
> engine API symbols and the build will fail.
>
> Fedora is currently providing a bridge package openssl-devel-engine [3] to
> help make the API transition easier, but that is only a temporary
> solution. (I think Debian is currently doing something similar.)
>
> [3] https://packages.fedoraproject.org/pkgs/openssl/openssl-devel-engine/
>
>> > The Kconfig option OPENSSL_NO_DEPRECATED introduces support for the
>> 
>> Please consider renaming this, OpenSSL itself uses OPENSSL_NO_DEPRECATED
>> constants for many things. I would recommend simply renaming to
>> OPENSSL_NO_ENGINE which is also the symbol OpenSSL is using. If there comes
>> a time we have more OPENSSL_NO_ options, we can always have a "virtual"
>> symbol called OPENSSL_NO_DEPRECATED which would select them all if one
>> wanted for example.
>> 
>
> I did give some thought to using a different name because I don't
> like the double negative that comes from this construct:
>
>     #ifndef CONFIG_OPENSSL_NO_DEPRECATED
>
> But I kept it because the name is advantageous precisely because it's
> already recognized by the OpenSSL API. OPENSSL_NO_DEPRECATED is a
> user-defined macro.[4] When combined with the OPENSSL_API_COMPAT macro,
> which is already defined in lib/rsa/rsa-sign.c, we can ensure that
> deprecated symbols won't be available in sections where
> OPENSSL_NO_DEPRECATED is defined.

I also don't linke this double negative.
As you already shared, Linux solved this via:

#if OPENSSL_VERSION_MAJOR >= 3

Why can't we have something similar?
See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=558bdc45dfb2669e1741384a0c80be9c82fa052c

>
> [4] https://docs.openssl.org/3.0/man7/openssl_user_macros/
>
>> > Provider API while continuing to use the existing Engine API on distros
>> > shipping older releases of OpenSSL.
>> > 
>> 
>> One can use org.openssl.engine: as prefix for provider arguments when one
>> wants to use an engine still.
>> 
>
> Sorry, but it's not clear what you are referring to here.
>
>> > This is based on similar work contributed by Jan Stancek updating Linux
>> > to use the Provider interface.
>> > 
>> >      commit 558bdc45dfb2669e1741384a0c80be9c82fa052c
>> >      Author: Jan Stancek <jstancek@redhat.com>
>> >      Date:   Fri Sep 20 19:52:48 2024 +0300
>> > 
>> >          sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3
>> > 
>> > The changes have been tested with the FIT signature verification vboot
>> > tests on Fedora 42 and Debian 13. All 30 tests pass with both the legacy
>> > Engine library installed and with the Provider API.
>> > 
>> 
>> Are there actually tests using an OpenSSL engine? Because otherwise it's
>> simply checking that local keys are still working... which isn't that much
>> different from what we currently have with engines when not using engines.
>> 
>> I'm implementing FIT images signing with OpenSSL engines, and it'd be nice
>> if we could have something that doesn't require changes to support providers
>> (or if it does, not in a confusing manner for example).
>> 
>> https://lore.kernel.org/u-boot/20251031-binman-engine-v1-0-c13c1b5dac43@cherry.de/T/#t
>> for the v1, I'll soon (next hours or tomorrow) post a v2 and Cc you if you
>> don't mind.
>> 
>> [...]
>> 
>
> As mentioned above, the motivation for this patch is that the Engine
> API has already been deprecated. Projects that depend on OpenSSL will
> need to move to the new Provider API in order to continue to function.
>
> The FIT Signature Verification tests I used to exercise both APIs are
> documented here.[5]
>
> [5] https://docs.u-boot.org/en/latest/usage/fit/signature.html#u-boot-fit-signature-verification
>
>
>> > diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
>> > index 9033384e60a3..1bf0ac96d598 100644
>> > --- a/lib/rsa/Kconfig
>> > +++ b/lib/rsa/Kconfig
>> > @@ -20,6 +20,13 @@ config SPL_RSA
>> >          bool "Use RSA Library within SPL"
>> >          depends on SPL
>> > 
>> > +config OPENSSL_NO_DEPRECATED
>> > +       bool "Build U-Boot without support for OpenSSL Engine"
>> > +       help
>> > +         Add support for the OpenSSL Provider API, which is the officially
>> > +         supported mechanism in OpenSSL 3.x and later releases for accessing
>> > +         hardware and software cryptography.
>> > +
>> 
>> mmmm Cannot we use providers for something else than RSA? In which case it's
>> a bit odd to have it in lib/rsa/Kconfig (but I have no better suggestion).
>> 
>
> To the best of my knowledge, the only areas in the U-Boot source that
> are using the Engine API are the RSA and AES libraries. All other uses
> in U-Boot are clients of these two libraries.
>
>> >   config SPL_RSA_VERIFY
>> >          bool
>> >          depends on SPL_RSA
>> 
>> [...]
>> 
>> > @@ -207,6 +247,37 @@ static int rsa_pem_get_priv_key(const char *keydir, const char *name,
>> >                  return -ENOENT;
>> >          }
>> > 
>> > +#ifdef CONFIG_OPENSSL_NO_DEPRECATED
>> > +       EVP_PKEY *private_key = NULL;
>> > +       OSSL_STORE_CTX *store;
>> > +
>> > +       if (!OSSL_PROVIDER_try_load(NULL, "pkcs11", true))
>> > +               ERR(1, "OSSL_PROVIDER_try_load(pkcs11)");
>> > +       if (!OSSL_PROVIDER_try_load(NULL, "default", true))
>> > +               ERR(1, "OSSL_PROVIDER_try_load(default)");
>> > +
>> > +       store = OSSL_STORE_open(path, NULL, NULL, NULL, NULL);
>> > +       ERR(!store, "OSSL_STORE_open");
>> > +
>> > +       while (!OSSL_STORE_eof(store)) {
>> > +               OSSL_STORE_INFO *info = OSSL_STORE_load(store);
>> > +
>> > +               if (!info) {
>> > +                       drain_openssl_errors(__LINE__, 0);
>> > +                       continue;
>> > +               }
>> > +               if (OSSL_STORE_INFO_get_type(info) == OSSL_STORE_INFO_PKEY) {
>> > +                       private_key = OSSL_STORE_INFO_get1_PKEY(info);
>> > +                       ERR(!private_key, "OSSL_STORE_INFO_get1_PKEY");
>> > +               }
>> > +               OSSL_STORE_INFO_free(info);
>> > +               if (private_key)
>> > +                       break;
>> > +       }
>> > +       OSSL_STORE_close(store);
>> > +
>> > +       *evpp = private_key;
>> > +#else
>> 
>> Wondering if it really makes sense to have the provider API implemented as
>> an #ifdef to save like 10 common lines between key-based and provider-based
>> implems.
>> 
>> On another topic, my first reading of the code makes me a bit worried by the
>> fact that there's seemingly no way to select whether we want to use a local
>> key or a provider key. Also, I see "pkcs11" and "default" here, but how do I
>> select which provider I want to use (e.g. my custom one). If I somehow
>> manage to have a key named the same locally and in one or more providers,
>> how do I make sure the proper one is selected? I'm wondering whether we
>> should be reusing the engine parameter to select a provider?
>> 
>> I have 0 security or crypto background, don't hesitate to be verbose in your
>> answer.
>> 
>> Cheers,
>> Quentin
>> 
>
> It's not the prettiest code. But I'm trying to be very conservative
> in making these changes so that no one's workflow is disrupted.
> Developers should be able to build U-Boot with the latest OpenSSL
> without impacting developers who are in environments utilizing the
> Engine API. The goal here is to preserve feature parity between the two
> APIs. Adding support for custom Providers is outside the scope of this
> change, but could certainly be added later.

I'd be in favor to drop CONFIG_OPENSSL_NO_DEPRECATED all together and
just use "#if OPENSSL_VERSION_MAJOR >= 3".

Tom, or anyone else, is there a particular` reason for gating this in a
Kconfig ?

The oldest Ubuntu version that seems supported (22.04) already has
OpenSSL version 3:

$ podman run -it /bin/bash ubuntu:22.04
root@6dc347676b8a:~# apt update && apt install -y openssl
root@6dc347676b8a:~# openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

>
> Eddie

Re: [PATCH v2] Add support for OpenSSL Provider API

[Eddie Kovsky]

On 12/11/25, Mattijs Korpershoek wrote:
> Hi Eddie,
> 
> Thank you for working on this. It would be really nice if we could build
> U-Boot on more recent Linux distros without bridge packages such as
> openssl-devel-engine.
> 
> 
> I also don't linke this double negative.
> As you already shared, Linux solved this via:
> 
> #if OPENSSL_VERSION_MAJOR >= 3
> 
> Why can't we have something similar?
> See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=558bdc45dfb2669e1741384a0c80be9c82fa052c
> 

Hi Mattijs

Yes, we could also implement it this way with the extra USE_PKCS11_XXX
symbol. Jan's original patch I based my work on does something similar,
and I perhaps oversimplified it.

> >
> > [4] https://docs.openssl.org/3.0/man7/openssl_user_macros/
> >
> >> > Provider API while continuing to use the existing Engine API on distros
> >> > shipping older releases of OpenSSL.
> >> > 
> >> 
> >> One can use org.openssl.engine: as prefix for provider arguments when one
> >> wants to use an engine still.
> >> 
> >
> > Sorry, but it's not clear what you are referring to here.
> >
> >> > This is based on similar work contributed by Jan Stancek updating Linux
> >> > to use the Provider interface.
> >> > 
> >> >      commit 558bdc45dfb2669e1741384a0c80be9c82fa052c
> >> >      Author: Jan Stancek <jstancek@redhat.com>
> >> >      Date:   Fri Sep 20 19:52:48 2024 +0300
> >> > 
> >> >          sign-file,extract-cert: use pkcs11 provider for OPENSSL MAJOR >= 3
> >> > 
> >> > The changes have been tested with the FIT signature verification vboot
> >> > tests on Fedora 42 and Debian 13. All 30 tests pass with both the legacy
> >> > Engine library installed and with the Provider API.
> >> > 
> >> 
> >> Are there actually tests using an OpenSSL engine? Because otherwise it's
> >> simply checking that local keys are still working... which isn't that much
> >> different from what we currently have with engines when not using engines.
> >> 
> >> I'm implementing FIT images signing with OpenSSL engines, and it'd be nice
> >> if we could have something that doesn't require changes to support providers
> >> (or if it does, not in a confusing manner for example).
> >> 
> >> https://lore.kernel.org/u-boot/20251031-binman-engine-v1-0-c13c1b5dac43@cherry.de/T/#t
> >> for the v1, I'll soon (next hours or tomorrow) post a v2 and Cc you if you
> >> don't mind.
> >> 
> >> [...]
> >> 
> >
> > As mentioned above, the motivation for this patch is that the Engine
> > API has already been deprecated. Projects that depend on OpenSSL will
> > need to move to the new Provider API in order to continue to function.
> >
> > The FIT Signature Verification tests I used to exercise both APIs are
> > documented here.[5]
> >
> > [5] https://docs.u-boot.org/en/latest/usage/fit/signature.html#u-boot-fit-signature-verification
> >
> >
> >> > diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
> >> > index 9033384e60a3..1bf0ac96d598 100644
> >> > --- a/lib/rsa/Kconfig
> >> > +++ b/lib/rsa/Kconfig
> >> > @@ -20,6 +20,13 @@ config SPL_RSA
> >> >          bool "Use RSA Library within SPL"
> >> >          depends on SPL
> >> > 
> >> > +config OPENSSL_NO_DEPRECATED
> >> > +       bool "Build U-Boot without support for OpenSSL Engine"
> >> > +       help
> >> > +         Add support for the OpenSSL Provider API, which is the officially
> >> > +         supported mechanism in OpenSSL 3.x and later releases for accessing
> >> > +         hardware and software cryptography.
> >> > +
> >> 
> >> mmmm Cannot we use providers for something else than RSA? In which case it's
> >> a bit odd to have it in lib/rsa/Kconfig (but I have no better suggestion).
> >> 
> >
> > To the best of my knowledge, the only areas in the U-Boot source that
> > are using the Engine API are the RSA and AES libraries. All other uses
> > in U-Boot are clients of these two libraries.
> >
> >> >   config SPL_RSA_VERIFY
> >> >          bool
> >> >          depends on SPL_RSA
> >> 
> >> [...]
> >> 
> >> > @@ -207,6 +247,37 @@ static int rsa_pem_get_priv_key(const char *keydir, const char *name,
> >> >                  return -ENOENT;
> >> >          }
> >> > 
> >> > +#ifdef CONFIG_OPENSSL_NO_DEPRECATED
> >> > +       EVP_PKEY *private_key = NULL;
> >> > +       OSSL_STORE_CTX *store;
> >> > +
> >> > +       if (!OSSL_PROVIDER_try_load(NULL, "pkcs11", true))
> >> > +               ERR(1, "OSSL_PROVIDER_try_load(pkcs11)");
> >> > +       if (!OSSL_PROVIDER_try_load(NULL, "default", true))
> >> > +               ERR(1, "OSSL_PROVIDER_try_load(default)");
> >> > +
> >> > +       store = OSSL_STORE_open(path, NULL, NULL, NULL, NULL);
> >> > +       ERR(!store, "OSSL_STORE_open");
> >> > +
> >> > +       while (!OSSL_STORE_eof(store)) {
> >> > +               OSSL_STORE_INFO *info = OSSL_STORE_load(store);
> >> > +
> >> > +               if (!info) {
> >> > +                       drain_openssl_errors(__LINE__, 0);
> >> > +                       continue;
> >> > +               }
> >> > +               if (OSSL_STORE_INFO_get_type(info) == OSSL_STORE_INFO_PKEY) {
> >> > +                       private_key = OSSL_STORE_INFO_get1_PKEY(info);
> >> > +                       ERR(!private_key, "OSSL_STORE_INFO_get1_PKEY");
> >> > +               }
> >> > +               OSSL_STORE_INFO_free(info);
> >> > +               if (private_key)
> >> > +                       break;
> >> > +       }
> >> > +       OSSL_STORE_close(store);
> >> > +
> >> > +       *evpp = private_key;
> >> > +#else
> >> 
> >> Wondering if it really makes sense to have the provider API implemented as
> >> an #ifdef to save like 10 common lines between key-based and provider-based
> >> implems.
> >> 
> >> On another topic, my first reading of the code makes me a bit worried by the
> >> fact that there's seemingly no way to select whether we want to use a local
> >> key or a provider key. Also, I see "pkcs11" and "default" here, but how do I
> >> select which provider I want to use (e.g. my custom one). If I somehow
> >> manage to have a key named the same locally and in one or more providers,
> >> how do I make sure the proper one is selected? I'm wondering whether we
> >> should be reusing the engine parameter to select a provider?
> >> 
> >> I have 0 security or crypto background, don't hesitate to be verbose in your
> >> answer.
> >> 
> >> Cheers,
> >> Quentin
> >> 
> >
> > It's not the prettiest code. But I'm trying to be very conservative
> > in making these changes so that no one's workflow is disrupted.
> > Developers should be able to build U-Boot with the latest OpenSSL
> > without impacting developers who are in environments utilizing the
> > Engine API. The goal here is to preserve feature parity between the two
> > APIs. Adding support for custom Providers is outside the scope of this
> > change, but could certainly be added later.
> 
> I'd be in favor to drop CONFIG_OPENSSL_NO_DEPRECATED all together and
> just use "#if OPENSSL_VERSION_MAJOR >= 3".
> 
> Tom, or anyone else, is there a particular` reason for gating this in a
> Kconfig ?
> 
> The oldest Ubuntu version that seems supported (22.04) already has
> OpenSSL version 3:
> 
> $ podman run -it /bin/bash ubuntu:22.04
> root@6dc347676b8a:~# apt update && apt install -y openssl
> root@6dc347676b8a:~# openssl version
> OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
> 

I assumed that we would want this to be an explicit config option, but
logically there is no reason that it has to be. I'd be happy to spin up
a v3 if there's agreement that the Kconfig isn't needed.

Eddie

Re: [PATCH v2] Add support for OpenSSL Provider API

[Mattijs Korpershoek]

On Mon, Dec 22, 2025 at 10:38, Eddie Kovsky <ekovsky@redhat.com> wrote:

> On 12/11/25, Mattijs Korpershoek wrote:
>> Hi Eddie,
>> 
>> Thank you for working on this. It would be really nice if we could build
>> U-Boot on more recent Linux distros without bridge packages such as
>> openssl-devel-engine.
>> 
>> 
>> I also don't linke this double negative.
>> As you already shared, Linux solved this via:
>> 
>> #if OPENSSL_VERSION_MAJOR >= 3
>> 
>> Why can't we have something similar?
>> See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=558bdc45dfb2669e1741384a0c80be9c82fa052c
>> 
>
> Hi Mattijs
>
> Yes, we could also implement it this way with the extra USE_PKCS11_XXX
> symbol. Jan's original patch I based my work on does something similar,
> and I perhaps oversimplified it.

In my experience, when porting things from the Linux kernel into U-Boot,
we try to keep the code as similar as possible. This helps reducing
maintainance burden.

Sometimes, we can't do that. In that case, we should explain why.

Do we have a strong reason for *not* reusing OPENSSL_VERSION_MAJOR with
USE_PKCS11_XXX ?

[...]

>> >> 
>> >
>> > It's not the prettiest code. But I'm trying to be very conservative
>> > in making these changes so that no one's workflow is disrupted.
>> > Developers should be able to build U-Boot with the latest OpenSSL
>> > without impacting developers who are in environments utilizing the
>> > Engine API. The goal here is to preserve feature parity between the two
>> > APIs. Adding support for custom Providers is outside the scope of this
>> > change, but could certainly be added later.
>> 
>> I'd be in favor to drop CONFIG_OPENSSL_NO_DEPRECATED all together and
>> just use "#if OPENSSL_VERSION_MAJOR >= 3".
>> 
>> Tom, or anyone else, is there a particular` reason for gating this in a
>> Kconfig ?
>> 
>> The oldest Ubuntu version that seems supported (22.04) already has
>> OpenSSL version 3:
>> 
>> $ podman run -it /bin/bash ubuntu:22.04
>> root@6dc347676b8a:~# apt update && apt install -y openssl
>> root@6dc347676b8a:~# openssl version
>> OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
>> 
>
> I assumed that we would want this to be an explicit config option, but
> logically there is no reason that it has to be. I'd be happy to spin up
> a v3 if there's agreement that the Kconfig isn't needed.

Tom, do you have an opinion on this? It seems you are listed as
maintainer for this (THE REST).

>
> Eddie

Re: [PATCH v2] Add support for OpenSSL Provider API

[Tom Rini]

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

On Mon, Jan 05, 2026 at 10:36:04AM +0100, Mattijs Korpershoek wrote:
> On Mon, Dec 22, 2025 at 10:38, Eddie Kovsky <ekovsky@redhat.com> wrote:
> 
> > On 12/11/25, Mattijs Korpershoek wrote:
> >> Hi Eddie,
> >> 
> >> Thank you for working on this. It would be really nice if we could build
> >> U-Boot on more recent Linux distros without bridge packages such as
> >> openssl-devel-engine.
> >> 
> >> 
> >> I also don't linke this double negative.
> >> As you already shared, Linux solved this via:
> >> 
> >> #if OPENSSL_VERSION_MAJOR >= 3
> >> 
> >> Why can't we have something similar?
> >> See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=558bdc45dfb2669e1741384a0c80be9c82fa052c
> >> 
> >
> > Hi Mattijs
> >
> > Yes, we could also implement it this way with the extra USE_PKCS11_XXX
> > symbol. Jan's original patch I based my work on does something similar,
> > and I perhaps oversimplified it.
> 
> In my experience, when porting things from the Linux kernel into U-Boot,
> we try to keep the code as similar as possible. This helps reducing
> maintainance burden.
> 
> Sometimes, we can't do that. In that case, we should explain why.
> 
> Do we have a strong reason for *not* reusing OPENSSL_VERSION_MAJOR with
> USE_PKCS11_XXX ?
> 
> [...]
> 
> >> >> 
> >> >
> >> > It's not the prettiest code. But I'm trying to be very conservative
> >> > in making these changes so that no one's workflow is disrupted.
> >> > Developers should be able to build U-Boot with the latest OpenSSL
> >> > without impacting developers who are in environments utilizing the
> >> > Engine API. The goal here is to preserve feature parity between the two
> >> > APIs. Adding support for custom Providers is outside the scope of this
> >> > change, but could certainly be added later.
> >> 
> >> I'd be in favor to drop CONFIG_OPENSSL_NO_DEPRECATED all together and
> >> just use "#if OPENSSL_VERSION_MAJOR >= 3".
> >> 
> >> Tom, or anyone else, is there a particular` reason for gating this in a
> >> Kconfig ?
> >> 
> >> The oldest Ubuntu version that seems supported (22.04) already has
> >> OpenSSL version 3:
> >> 
> >> $ podman run -it /bin/bash ubuntu:22.04
> >> root@6dc347676b8a:~# apt update && apt install -y openssl
> >> root@6dc347676b8a:~# openssl version
> >> OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
> >> 
> >
> > I assumed that we would want this to be an explicit config option, but
> > logically there is no reason that it has to be. I'd be happy to spin up
> > a v3 if there's agreement that the Kconfig isn't needed.
> 
> Tom, do you have an opinion on this? It seems you are listed as
> maintainer for this (THE REST).

Yes, sorry, I think part of the question here is how it plays out with
LibreSSL and other alternatives to openssl, which ends up being a Mark
question.

-- 
Tom

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

Re: [PATCH v2] Add support for OpenSSL Provider API

[Eddie Kovsky]

On 01/05/26, Tom Rini wrote:
> On Mon, Jan 05, 2026 at 10:36:04AM +0100, Mattijs Korpershoek wrote:
> > On Mon, Dec 22, 2025 at 10:38, Eddie Kovsky <ekovsky@redhat.com> wrote:
> > 
> > > On 12/11/25, Mattijs Korpershoek wrote:
> > >> Hi Eddie,
> > >> 
> > >> Thank you for working on this. It would be really nice if we could build
> > >> U-Boot on more recent Linux distros without bridge packages such as
> > >> openssl-devel-engine.
> > >> 
> > >> 
> > >> I also don't linke this double negative.
> > >> As you already shared, Linux solved this via:
> > >> 
> > >> #if OPENSSL_VERSION_MAJOR >= 3
> > >> 
> > >> Why can't we have something similar?
> > >> See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=558bdc45dfb2669e1741384a0c80be9c82fa052c
> > >> 
> > >
> > > Hi Mattijs
> > >
> > > Yes, we could also implement it this way with the extra USE_PKCS11_XXX
> > > symbol. Jan's original patch I based my work on does something similar,
> > > and I perhaps oversimplified it.
> > 
> > In my experience, when porting things from the Linux kernel into U-Boot,
> > we try to keep the code as similar as possible. This helps reducing
> > maintainance burden.
> > 
> > Sometimes, we can't do that. In that case, we should explain why.
> > 
> > Do we have a strong reason for *not* reusing OPENSSL_VERSION_MAJOR with
> > USE_PKCS11_XXX ?
> > 
> > [...]
> > 
> > >> >> 
> > >> >
> > >> > It's not the prettiest code. But I'm trying to be very conservative
> > >> > in making these changes so that no one's workflow is disrupted.
> > >> > Developers should be able to build U-Boot with the latest OpenSSL
> > >> > without impacting developers who are in environments utilizing the
> > >> > Engine API. The goal here is to preserve feature parity between the two
> > >> > APIs. Adding support for custom Providers is outside the scope of this
> > >> > change, but could certainly be added later.
> > >> 
> > >> I'd be in favor to drop CONFIG_OPENSSL_NO_DEPRECATED all together and
> > >> just use "#if OPENSSL_VERSION_MAJOR >= 3".
> > >> 
> > >> Tom, or anyone else, is there a particular` reason for gating this in a
> > >> Kconfig ?
> > >> 
> > >> The oldest Ubuntu version that seems supported (22.04) already has
> > >> OpenSSL version 3:
> > >> 
> > >> $ podman run -it /bin/bash ubuntu:22.04
> > >> root@6dc347676b8a:~# apt update && apt install -y openssl
> > >> root@6dc347676b8a:~# openssl version
> > >> OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
> > >> 
> > >
> > > I assumed that we would want this to be an explicit config option, but
> > > logically there is no reason that it has to be. I'd be happy to spin up
> > > a v3 if there's agreement that the Kconfig isn't needed.
> > 
> > Tom, do you have an opinion on this? It seems you are listed as
> > maintainer for this (THE REST).
> 
> Yes, sorry, I think part of the question here is how it plays out with
> LibreSSL and other alternatives to openssl, which ends up being a Mark
> question.
> 
> -- 
> Tom

I am being careful not to break backwards compatibility here. I've
written the patch so that anyone who needs to continue using the Engine
API can do so.

The LibreSSL project implements the OpenSSL 1.1 API, but does not
support the OpenSSL 3 API, and to be the best of my knowledge does not
intend to support the Provider interface. During the V1 discussion I did
ask Mark to verify that my patch preserves backwards compatibility with
LibreSSL as intended.

Tom, regarding the other question, would you prefer that I implement
this using just #ifdefs without the Kconfig option?

Eddie

Re: [PATCH v2] Add support for OpenSSL Provider API

[Tom Rini]

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

On Fri, Jan 16, 2026 at 12:00:49PM -0700, Eddie Kovsky wrote:
> On 01/05/26, Tom Rini wrote:
> > On Mon, Jan 05, 2026 at 10:36:04AM +0100, Mattijs Korpershoek wrote:
> > > On Mon, Dec 22, 2025 at 10:38, Eddie Kovsky <ekovsky@redhat.com> wrote:
> > > 
> > > > On 12/11/25, Mattijs Korpershoek wrote:
> > > >> Hi Eddie,
> > > >> 
> > > >> Thank you for working on this. It would be really nice if we could build
> > > >> U-Boot on more recent Linux distros without bridge packages such as
> > > >> openssl-devel-engine.
> > > >> 
> > > >> 
> > > >> I also don't linke this double negative.
> > > >> As you already shared, Linux solved this via:
> > > >> 
> > > >> #if OPENSSL_VERSION_MAJOR >= 3
> > > >> 
> > > >> Why can't we have something similar?
> > > >> See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=558bdc45dfb2669e1741384a0c80be9c82fa052c
> > > >> 
> > > >
> > > > Hi Mattijs
> > > >
> > > > Yes, we could also implement it this way with the extra USE_PKCS11_XXX
> > > > symbol. Jan's original patch I based my work on does something similar,
> > > > and I perhaps oversimplified it.
> > > 
> > > In my experience, when porting things from the Linux kernel into U-Boot,
> > > we try to keep the code as similar as possible. This helps reducing
> > > maintainance burden.
> > > 
> > > Sometimes, we can't do that. In that case, we should explain why.
> > > 
> > > Do we have a strong reason for *not* reusing OPENSSL_VERSION_MAJOR with
> > > USE_PKCS11_XXX ?
> > > 
> > > [...]
> > > 
> > > >> >> 
> > > >> >
> > > >> > It's not the prettiest code. But I'm trying to be very conservative
> > > >> > in making these changes so that no one's workflow is disrupted.
> > > >> > Developers should be able to build U-Boot with the latest OpenSSL
> > > >> > without impacting developers who are in environments utilizing the
> > > >> > Engine API. The goal here is to preserve feature parity between the two
> > > >> > APIs. Adding support for custom Providers is outside the scope of this
> > > >> > change, but could certainly be added later.
> > > >> 
> > > >> I'd be in favor to drop CONFIG_OPENSSL_NO_DEPRECATED all together and
> > > >> just use "#if OPENSSL_VERSION_MAJOR >= 3".
> > > >> 
> > > >> Tom, or anyone else, is there a particular` reason for gating this in a
> > > >> Kconfig ?
> > > >> 
> > > >> The oldest Ubuntu version that seems supported (22.04) already has
> > > >> OpenSSL version 3:
> > > >> 
> > > >> $ podman run -it /bin/bash ubuntu:22.04
> > > >> root@6dc347676b8a:~# apt update && apt install -y openssl
> > > >> root@6dc347676b8a:~# openssl version
> > > >> OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
> > > >> 
> > > >
> > > > I assumed that we would want this to be an explicit config option, but
> > > > logically there is no reason that it has to be. I'd be happy to spin up
> > > > a v3 if there's agreement that the Kconfig isn't needed.
> > > 
> > > Tom, do you have an opinion on this? It seems you are listed as
> > > maintainer for this (THE REST).
> > 
> > Yes, sorry, I think part of the question here is how it plays out with
> > LibreSSL and other alternatives to openssl, which ends up being a Mark
> > question.
> > 
> > -- 
> > Tom
> 
> I am being careful not to break backwards compatibility here. I've
> written the patch so that anyone who needs to continue using the Engine
> API can do so.
> 
> The LibreSSL project implements the OpenSSL 1.1 API, but does not
> support the OpenSSL 3 API, and to be the best of my knowledge does not
> intend to support the Provider interface. During the V1 discussion I did
> ask Mark to verify that my patch preserves backwards compatibility with
> LibreSSL as intended.
> 
> Tom, regarding the other question, would you prefer that I implement
> this using just #ifdefs without the Kconfig option?

Yes, lets follow the kernel's example with just #ifdefs, thanks.

-- 
Tom

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