On Fri, Jun 06, 2025 at 09:19:18AM +0200, Harald Freudenberger wrote: > > The crypto self-tests remain disabled by default; there's just no longer > > a > > difference between the "regular tests" and the "full tests". The > > warning makes > > sense to me. There should be an indication that the tests are running > > since > > they take a long time and should not be enabled in production kernels. > > > > If this is s390, arch/s390/configs/defconfig has > > CONFIG_CRYPTO_SELFTESTS=y. Is > > that really what you want? I tried to remove it as part of > > https://lore.kernel.org/linux-crypto/20250419161543.139344-4-ebiggers@xxxxxxxxxx/, > > but someone complained about that patch so I ended up dropping it. But > > maybe > > you still want to remove it from arch/s390/configs/defconfig. There's > > already > > arch/s390/configs/debug_defconfig that has it enabled too, and maybe you > > only > > want tests enabled in the "debug" one? > > > > - Eric > > Looks like we have no other options than disabling the selftests in > defconfig. > We have debug_defconfig - with all the now huge set of test running in CI. > But for my feeling it was making total sense to have a subset of the tests > run with registration of each crypto algorithm even in production kernels. > However, as wrote ... there is no choice anymore. There's still a command-line option cryptomgr.noslowtests=1. If you really want it, we could add back a kconfig option to control whether the self-tests run the "fast" tests only or not. I thought that the only use case for running the "fast" tests only was for people who are misusing these tests for FIPS pre-operational self-testing. (Which has always been a poor match, as FIPS requires only a single test of any length per algorithm, for only a subset of algorithms. It's totally different from actually doing proper testing.) Those people should be okay with the command-line option. I do think the idea of running the tests in production kernels is questionable. There are enough tests now that you can't run all of them (and indeed you are not asking for that), which means the production testing will be incomplete, and the real testing needs to be done in the development phase with a build that has the tests enabled anyway. The same applies to other kernel subsystems too. - Eric
