On Mon, Jun 16, 2025 at 12:50:07PM +0200, Harald Freudenberger wrote: > On 2025-06-06 19:45, Eric Biggers wrote: > > 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 > > In general I agree to this. Clearly it makes no sense to run all > the tests all time when a new algorithm is registered. > The thing is ... everybody wants to test as close as possible to the > production systems. So the kernels are usually build for production - now > without > any selftests. But all the Linux distributors happily patch whatever they > think > is necessary and build production kernels - now without any in-kernel crypto > selftests. The only places where selftests are now executed is in 'special' > environments like CIs or on development systems and hopefully findings there > are handled seriously by the maintainers and developers. > > Harald Freudenberger FYI: due to all the buggy hardware drivers and distros wanting to enable the crypto self-tests in production, we did decide to restore the ability to run only the "fast" crypto self-tests. See: https://lore.kernel.org/r/20250612174709.26990-1-ebiggers@xxxxxxxxxx/ The full tests will once again not be enabled in any of the defconfigs. You may want to enable CRYPTO_SELFTESTS_FULL in arch/s390/configs/debug_defconfig. - Eric
