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