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
