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 [email protected]. 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 <[email protected]>
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/[email protected]/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
