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: Mon, 16 Jun 2025 08:58:37 -0700 [thread overview]
Message-ID: <20250616155837.GA1373@sol> (raw)
In-Reply-To: <319c7c1d4af5c1014d4a88ade39207ea@linux.ibm.com>
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@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
>
> 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@kernel.org/
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
next prev parent reply other threads:[~2025-06-16 15:59 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
2025-06-16 10:50 ` Harald Freudenberger
2025-06-16 15:58 ` Eric Biggers [this message]
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=20250616155837.GA1373@sol \
--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.