Hi Tom, On Tue, 2 Dec 2025 at 20:14, Tom Rini <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > > > > wrote: > > > >> > > > >> From: Quentin Schulz <[email protected]> > > > >> > > > >> 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 <[email protected]> > > > >> --- > > > >> 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/[email protected]/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.
Well in that case, just put the change log in each patch as well as the cover letter. It should not be difficult to support that in b4...I think patman has supported it for 10 years now. We are the humans and the tools should work for us! Regards, Simon
