Re: [PATCH] crypto: testmgr - reinstate kconfig support for fast tests only

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Jun 11, 2025 at 08:53:17PM +0200, Diederik de Haas wrote:
> I was about to respond to your reply, but I guess this may be a better
> fit for it. The TL;DR: version is this:
> 
> If you think distros shouldn't enable it, as you initially clearly
> described and it seems to me you still think so, the right thing for
> distros to do, is to disable those test. Which in turn means the fast
> tests should not be reinstated (?).
> 
> On Wed Jun 11, 2025 at 7:55 PM CEST, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > Commit 698de822780f ("crypto: testmgr - make it easier to enable the
> > full set of tests") removed support for building kernels that run only
> > the "fast" set of crypto self-tests by default.  This assumed that
> > nearly everyone actually wanted the full set of tests, *if* they had
> > already chosen to enable the tests at all.
> >
> > Unfortunately, it turns out that both Debian and Fedora have the crypto
> > self-tests enabled in their production kernels, and they seem to want to
> 
> I explicitly referenced https://bugs.debian.org/599441 as that was the
> only justification I found for enabling it.
> In it, on 2010-10-07 "Mario 'BitKoenig' Holbe" said:
> 
>   I personally think (re)enabling these tests would be a way safer
>   default for a distribution kernel which runs on lots of different
>   hardware setups
> 
> Before I looked up that bug, I had not heard of that person, so I don't
> know if they're a crypto expert or just a random person on the internet.
> It also doesn't say *why* they thought it would be a good idea to enable
> those tests.
> I have no idea what Fedora's reasoning was for enabling it. Maybe their
> reasons were sound; I think Debian's are rather thin (that I could
> find). And from ~ 15 years ago.
> 
> > keep them enabled.  The full set of tests isn't great for that, since
> 
> I think the 'new' description is(/was) great. A subject matter expert
> says/said "don't enable this on production kernels". I wish all Kconfig
> help texts were this clear :-)
> So based on the previous description, it seems wise that Debian (and
> Fedora) would update their kernel config and disable those test.
> 
> In *my* update to 6.16-rc1, I only 'converted' to new names.
> A change to my kernel config (ie disable the tests) would be in a
> separate commit (with an appropriate commit msg).
> I hadn't done that yet as I was curious what the results would be.
> 
> So "they seem to want to keep them enabled" seems a premature
> conclusion; at least wrt Debian and AFAICT.
> It's also possible that if/when people see the kernel warning, they'd
> file a new Debian bug to have it disabled.
> 
> (I've made some contributions in the past, but) I am not part of
> Debian's kernel team, so I don't know what they will decide.
>  
> I'll gladly leave it up to you if you still think reinstating the fast
> tests is worth it, but I felt a bit more context was warranted.
> 
> Cheers,
>   Diederik

I mean, not enabling the tests in production is how it should be.

But Fedora already enabled CRYPTO_SELFTESTS, apparently because of FIPS
(https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3886).

You're right there doesn't seem to be an up-to-date bug for Debian
(https://bugs.debian.org/599441 is old), so maybe my conclusion is premature.

However, besides FIPS I think the problem is that the crypto/ philosophy is to
throw untested and broken hardware drivers over the wall at users.  As long as
that's the case, the self-tests do actually have some value in protecting users
from those drivers, even though that's not how it should be.

- Eric