[PATCH v2] Add support for OpenSSL Provider API
Quentin Schulz
quentin.schulz at cherry.de
Thu May 21 19:45:14 CEST 2026
Hi Eddie,
I'm only a couple of months late to the party :)
On 11/21/25 7:16 PM, Eddie Kovsky 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 at 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.
>
That does not seem to be true.
host$ podman run -it --rm --security-opt label=disable --userns keep-id
-w $PWD -v $PWD:$PWD docker.io/debian:trixie
host$ podman exec -it --user root --latest apt-get --update install -y
build-essential make bison flex bc rsync kmod cpio libssl-dev
gcc-aarch64-linux-gnu debhelper ncurses-dev python3-pyelftools
python3-setuptools swig python3-dev
container$ touch bl31.elf
container$ export BL31.elf
container$ make CROSS_COMPILE="aarch64-linux-gnu-" O=build/ringneck
ringneck-px30_defconfig
container$ make CROSS_COMPILE="aarch64-linux-gnu-" O=build/ringneck
-j`nproc`
You can then see that
./build/ringneck/tools/generated/lib/rsa/rsa-sign.o is built.
host$ podman run -it --rm --security-opt label=disable --userns keep-id
-w $PWD -v $PWD:$PWD docker.io/archlinux/archlinux:latest
host$ podman exec -it --user root --latest pacman -Sy openssl swig
python python-setuptools make gcc bison flex bc rsync kmod cpio
python-pyelftools aarch64-linux-gnu-gcc
container$ touch bl31.elf
container$ export BL31.elf
container$ make CROSS_COMPILE="aarch64-linux-gnu-" O=build/ringneck
ringneck-px30_defconfig
container$ make CROSS_COMPILE="aarch64-linux-gnu-" O=build/ringneck
-j`nproc`
You can then see that
./build/ringneck/tools/generated/lib/rsa/rsa-sign.o is built.
I'm also pretty sure OpenSSL is built with engine support in Fedora even
without openssl-devel-engine since I could run the binman test suite
using the openssl pkcs11 engine in Fedora without that package.
Some OpenSSL engines are available in the official package feeds:
$ dnf provides '/usr/lib64/engines-3/*'
Updating and loading repositories:
Repositories loaded.
openssl-libs-1:3.5.5-2.fc44.x86_64 : A general purpose cryptography
library with TLS implementation
Repo : @System
Matched From :
Filename : /usr/lib64/engines-3/afalg.so
Filename : /usr/lib64/engines-3/capi.so
Filename : /usr/lib64/engines-3/loader_attic.so
Filename : /usr/lib64/engines-3/padlock.so
openssl-pkcs11-0.4.13-4.fc44.x86_64 : A PKCS#11 engine for use with OpenSSL
Repo : @System
Matched From :
Filename : /usr/lib64/engines-3/libpkcs11.so
Filename : /usr/lib64/engines-3/pkcs11.so
openssl-gost-engine-3.0.3-11.fc44.x86_64 : A reference implementation of
the Russian GOST crypto algorithms for OpenSSL
Repo : fedora
Matched From :
Filename : /usr/lib64/engines-3/README.gost
Filename : /usr/lib64/engines-3/gost.so
openssl-libs-1:3.5.5-1.fc44.x86_64 : A general purpose cryptography
library with TLS implementation
Repo : fedora
Matched From :
Filename : /usr/lib64/engines-3/afalg.so
Filename : /usr/lib64/engines-3/capi.so
Filename : /usr/lib64/engines-3/loader_attic.so
Filename : /usr/lib64/engines-3/padlock.so
openssl-pkcs11-0.4.13-4.fc44.x86_64 : A PKCS#11 engine for use with OpenSSL
Repo : fedora
Matched From :
Filename : /usr/lib64/engines-3/libpkcs11.so
Filename : /usr/lib64/engines-3/pkcs11.so
p11-remote-0.3-23.fc44.x86_64 : Remoting of PKCS#11 modules across sessions
Repo : fedora
Matched From :
Filename : /usr/lib64/engines-3/libp11-kit-engine.so
tpm2-tss-engine-1.2.0-9.fc44.x86_64 : OpenSSL Engine for TPM2 devices
using the tpm2-tss software stack
Repo : fedora
Matched From :
Filename : /usr/lib64/engines-3/libtpm2tss.so
Filename : /usr/lib64/engines-3/tpm2tss.so
openssl-libs-1:3.5.5-2.fc44.x86_64 : A general purpose cryptography
library with TLS implementation
Repo : updates
Matched From :
Filename : /usr/lib64/engines-3/afalg.so
Filename : /usr/lib64/engines-3/capi.so
Filename : /usr/lib64/engines-3/loader_attic.so
Filename : /usr/lib64/engines-3/padlock.so
$ openssl engine dynamic -c pkcs11
(dynamic) Dynamic engine loading support
(pkcs11) pkcs11 engine
So it seems the only thing Fedora (and RHEL and other Red Hat distros I
guess) is doing is moving openssl/engine.h (and a few others) to a
different package.
Note that Fedora modifies /usr/include/openssl/configuration-x86_64.h to add
# if !__has_include(<openssl/engine.h>) && !defined(OPENSSL_NO_ENGINE)
# define OPENSSL_NO_ENGINE
# endif
which is kinda odd since technically, OpenSSL is built with engine
support, regardless of openssl/engine.h presence on your system. It does
however prevent you from building a new engine. I'm honestly not sure
what the intent is by moving this to a separate package? Fail everybody
but provide a fallback until OpenSSL 4.x is packaged where the fallback
won't be available anymore?
Note that OpenSSL 4.x still ships an engine.h, although with stubs (if
OPENSSL_ENGINE_STUBS is defined).
> 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.)
>
Considering Debian happily compiles rsa-sign.o as well as the dummy RSA
engine in tools/binman/test/fit with
gcc -lcrypto -lssl dummy-rsa-engine.c -fPIC -shared -o dummy-rsa-engine.so
I'm not sure that's true, do you have a source for that?
> [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.
>
I meant to say one can still use engines without using the engine API
explicitly, by using org.openssl.engine:<engine>: scheme in
OSSL_STORE_open() for example or when a key is requested on the openssl CLI.
>>> This is based on similar work contributed by Jan Stancek updating Linux
>>> to use the Provider interface.
>>>
>>> commit 558bdc45dfb2669e1741384a0c80be9c82fa052c
>>> Author: Jan Stancek <jstancek at 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.
>
Yes. At the same time, OpenSSL 3.5 is supported until April 2030 so
until we are a few years after that, we'll probably still need to
support engines.
> 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
>
Did you follow
https://docs.u-boot.org/en/latest/usage/fit/signature.html#hardware-signing-with-pkcs-11-or-with-hsm
which I believe is the only section which uses an engine? Specifically,
the last code snippet "Sign the fitImage with the hardware key:".
I don't think we have any test in ./test/py/test.py --bd sandbox --build
-k vboot using engines (git grep -E 'pkcs11|engine' test/py doesn't
return anything).
Cheers,
Quentin
More information about the U-Boot
mailing list