[PATCH v3 4/4] tools: binman: fit: add tests for signing with an OpenSSL engine

[Tom Rini]

On Thu, Dec 04, 2025 at 12:52:17PM +0100, Quentin Schulz wrote:
> Hi Tom,
> 
> On 12/2/25 9:14 PM, Tom Rini wrote:
> > On Tue, Dec 02, 2025 at 08:06:02PM +0000, Simon Glass wrote:
> > > Hi Quentin,
> > > 
> > > On Wed, 26 Nov 2025 at 04:44, Quentin Schulz <quentin.schulz at cherry.de> wrote:
> > > > 
> > > > Hi Simon,
> > > > 
> > > > On 11/25/25 11:15 PM, Simon Glass wrote:
> > > > > Hi Quentin,
> > > > > 
> > > > > On Fri, 21 Nov 2025 at 10:15, Quentin Schulz <foss+uboot at 0leil.net> wrote:
> > > > > > 
> > > > > > From: Quentin Schulz <quentin.schulz at cherry.de>
> > > > > > 
> > > > > > This adds a test that signs a FIT and verifies the signature with
> > > > > > fit_check_sign.
> > > > > > 
> > > > > > OpenSSL engines are typically for signing with external HW so it's not
> > > > > > that straight-forward to simulate.
> > > > > > 
> > > > > > For a simple RSA OpenSSL engine, a dummy engine with a hardcoded RSA
> > > > > > 4096 private key is made available. It can be selected by setting the
> > > > > > OpenSSL engine argument to dummy-rsa-engine. This can only be done if
> > > > > > the engine is detected by OpenSSL, which works by setting the
> > > > > > OPENSSL_ENGINES environment variable. I have no clue if dummy-rsa-engine
> > > > > > is properly implementing what is expected from an RSA engine, but it
> > > > > > seems to be enough for testing.
> > > > > > 
> > > > > > For a simple PKCS11 engine, SoftHSMv2 is used, which allows to do PKCS11
> > > > > > without specific hardware. The keypairs and tokens are generated on the
> > > > > > fly. The "prod" token is generated with a different PIN (1234 instead of
> > > > > > 1111) to also test MKIMAGE_SIGN_PIN env variable while we're at it.
> > > > > > 
> > > > > > Binman will not mess with the local SoftHSMv2 setup as it will only use
> > > > > > tokens from a per-test temporary directory enforced via the temporary
> > > > > > configuration file set via SOFTHSM2_CONF env variable in the tests. The
> > > > > > files created in the input dir should NOT be named the same as it is
> > > > > > shared between all tests in the same process (which is all tests when
> > > > > > running binman with -P 1 or with -T).
> > > > > > 
> > > > > > Once signed, it's checked with fit_check_sign with the associated
> > > > > > certificate.
> > > > > > 
> > > > > > Finally, a new softhsm2_util bintool is added so that we can initialize
> > > > > > the token and import keypairs. On Debian, the package also brings
> > > > > > libsofthsm2 which is required for OpenSSL to interact with SoftHSMv2. It
> > > > > > is not the only package required though, as it also needs p11-kit and
> > > > > > libengine-pkcs11-openssl (the latter bringing the former). We can detect
> > > > > > if it's properly installed by running openssl engine dynamic -c pkcs11.
> > > > > > If that fails, we simply skip the test.
> > > > > > The package is installed in the CI container by default.
> > > > > > 
> > > > > > Signed-off-by: Quentin Schulz <quentin.schulz at cherry.de>
> > > > > > ---
> > > > > >    tools/binman/btool/softhsm2_util.py                |  21 ++
> > > > > >    tools/binman/ftest.py                              | 223 +++++++++++++++++++++
> > > > > >    tools/binman/test/340_dummy-rsa4096.crt            |  31 +++
> > > > > >    tools/binman/test/340_fit_signature_engine.dts     |  99 +++++++++
> > > > > >    .../test/340_fit_signature_engine_encrypt.dts      | 100 +++++++++
> > > > > >    .../test/340_fit_signature_engine_pkcs11.dts       |  99 +++++++++
> > > > > >    .../340_fit_signature_engine_pkcs11_object.dts     | 100 +++++++++
> > > > > >    tools/binman/test/340_openssl.conf                 |  10 +
> > > > > >    tools/binman/test/340_softhsm2.conf                |  16 ++
> > > > > >    tools/binman/test/Makefile                         |   6 +-
> > > > > >    tools/binman/test/dummy-rsa-engine.c               | 149 ++++++++++++++
> > > > > >    11 files changed, 853 insertions(+), 1 deletion(-)
> > > > > 
> > > > > Not sure of the changes from last time, but I assume the test coverage
> > > > > is finished.
> > > > > 
> > > > 
> > > > They are listed in the cover letter in the Changes section.
> > > > 
> > > > $ b4 diff -v 2 3 --
> > > > https://lore.kernel.org/u-boot/20251121-binman-engine-v3-0-b80180aaa783@cherry.de/T/\#t
> > > > 
> > > > will show you the git-range-diff between both versions for a given commit.
> > > 
> > > I normally review just in email (often on a Chromebook) so I don't
> > > have that. It is also an extra step and I don't know where your log
> > > argument comes from. It would be better to put the change log in the
> > > patch as well.
> > 
> > The cover letter is just an email. Perhaps a handy tips bit of
> > documentation (and external ref to the general b4 docs) would be
> > helpful, especially since b4 is a common and widely used tool these
> > days.
> 
> I can do that, what do you have in mind? What should we add to the docs?

Honestly, whatever you've found useful as a contributor and reviewer.
I'll follow-up with some handy things for custodians (mainly patchwork
integration and that cover letters are so important because it's an
automatic useful merge commit message). Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251204/9385c945/attachment.sig>