From: Eric Biggers <ebiggers@kernel.org>
To: Harald Freudenberger <freude@linux.ibm.com>
Cc: Ingo Franzki <ifranzki@linux.ibm.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
linux-crypto@vger.kernel.org, dengler@linux.ibm.com
Subject: Re: CI: Another strange crypto message in syslog
Date: Fri, 6 Jun 2025 17:45:08 +0000 [thread overview]
Message-ID: <20250606174508.GA53397@google.com> (raw)
In-Reply-To: <66d4c382f0fbe4ca5486ccfa1f0a4699@linux.ibm.com>
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@kernel.org/,
> > 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
next prev parent reply other threads:[~2025-06-06 17:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-05 11:26 CI: Another strange crypto message in syslog Ingo Franzki
2025-06-05 14:26 ` Eric Biggers
2025-06-06 7:19 ` Harald Freudenberger
2025-06-06 17:45 ` Eric Biggers [this message]
2025-06-16 10:50 ` Harald Freudenberger
2025-06-16 15:58 ` Eric Biggers
2025-06-10 12:37 ` Ingo Franzki
2025-06-10 19:16 ` [PATCH] crypto: hkdf - move to late_initcall Eric Biggers
2025-06-11 3:03 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250606174508.GA53397@google.com \
--to=ebiggers@kernel.org \
--cc=dengler@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=ifranzki@linux.ibm.com \
--cc=linux-crypto@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.