Hi all,
On 8/26/26 5:17 PM, Eddie Kovsky wrote:
On 08/22/26, Jaipaul Cheernam wrote:
Hi Eddie, Quentin,
We're currently working on upgrading OpenEmbedded-Core (Yocto Project) to
OpenSSL 4.0.1 and hit this exact issue — mkimage fails at FIT image signing
because it unconditionally tries to load the pkcs11 provider, which isn't
available in our build environment.
For our purposes, file-based key signing with just the default provider works
fine. We're carrying this patch with a local modification that makes the pkcs11
provider load non-fatal:
if (!OSSL_PROVIDER_try_load(NULL, "default", true))
ERR(1, "OSSL_PROVIDER_try_load(default)");
/* pkcs11 provider is optional; only needed for pkcs11: URIs */
if (!OSSL_PROVIDER_try_load(NULL, "pkcs11", true))
ERR_clear_error();
This allows signing to work without pkcs11-provider installed while still
loading it when available (for pkcs11: URI keys).
Is there a v5 in the works? Happy to test if it would help move this forward.
Thanks,
Jaipaul
Hi Jaipaul
Yes, I still intend to do a version 5. I have been very busy with my day
job recently. And refactoring the PKCS11 URI parsing adds another
wrinkle to sort out before I can provide an update.
I unfortunately didn't manage to find the time to polish my local series
for supporting OpenSSL providers before going out of office for the next
two weeks.
I've pushed a WIP branch on the u-boot-rockchip custodian repo. Please
pay no mind to where it's hosted, it's just the one repo I have access
to right now that has CI, it doesn't have anything to do with Rockchip.
https://git.u-boot-project.org/u-boot/custodians/u-boot-rockchip/-/tree/openssl-providers
CI should pass, but you never know. There are tests for private and
public keys being stored in an engine and provider. There are tests for
PKCS11 provider support, with the same logic as used for the PKCS11
engine support when it comes to handling keydir (-k). There is a test to
make sure mkimage built without engine support fails when passed a -N
argument, of course this only works on distros where
OpenSSL/OpenSSL-like doesn't support engines (so, Fedora 44 without
openssl-devel-engine package, or Fedora 45+).
I've tested locally with the binman test suite in
docker.io/trini/u-boot-gitlab-ci-runner:noble-20251013-23Jan2026
container, as well as fedora:44
(sha256:459d2bd81d249a52f7d4be6ffaeeb9fbad795501cdbe7be207c0745f5ad7de66)
with and without openssl-devel-engine installed and fedora:rawhide
(sha256:4412e0aaaa461370e89dd443ceb7f631c58dce34cc93686399c3488f01475041)
which has OpenSSL 4.x. On Fedora, you'll need:
dnf install gcc make python3-pip python3-virtualenv bison flex cmp swig
python3-devel gnutls-devel perl openssl pkcs11-provider softhsm2-util
lz4 python3-coverage openssl-devel pkcs11-tool lzop
(and possibly some other packages related to engines/providers). Follow
the instructions in .gitlab-ci.yml in the "Run binman, buildman, dtoc
and Kconfig testsuites" job and you should be set.
I've tried to run the binman test suite on Bullseye thinking it sure
doesn't support OpenSSL engines, but it actually seems to be able to
(OpenSSL 1.1.1w has support for it) and I get a segfault when running
mkimage -N dummy-rsa that I don't know how to debug (and I needed to
change the installed filelock version as it isn't compatible with Python
in Bullseye; we also have some Python 3.10+ syntax that cannot be used
in Bullseye either). Anyway, if someone knows how to setup a distro with
an OpenSSL (or OpenSSL-compatible implementation) which doesn't support
engines or providers, it would be nice to test this branch on. I still
need to test this with our (my employer) custom provider to make sure
this works, but an earlier version of this branch worked.
There are some things in this branch I quite dislike but couldn't think
of something nicer to do (piggy-backing on binman's test suite to
validate mkimage/fdt_add_pubkey works as expected; building and
executing a binary to tell us whether engines or providers are
supported, etc.). I didn't find a way to test whether the public key was
coming from a certificate from the provider or directly a public key
from the provider, so I didn't add a test for it (it is supported though).
Note that you must erase your build AND test directories whenever you
switch fedora 44 between openssl-devel-engine installed and removed as
the build system doesn't know that the content of the header files have
changed (and thus, our #ifdefs). I don't have a plan on how to address
this (if it even must be addressed).
I'm just sending this in case anyone wants to have a look at this before
I can resume work on this in two weeks time, hopefully avoiding
duplicating work. I'm not expecting a review or feedback from anyone.
This branch is based on this patch here, hence most of the "DO NOT
MERGE" commits that would likely be better squashed in a v5 for example.
I still see actual support of providers as being a separate topic so I
think starting from "DO NOT MERGE: rsa: add support for OpenSSL
providers" can be its own series.
Cheers,
Quentin
