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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250611190458.GA4097002@google.com>
Date: Wed, 11 Jun 2025 19:04:58 +0000
From: Eric Biggers <ebiggers@...nel.org>
To: Diederik de Haas <didi.debian@...ow.org>
Cc: linux-crypto@...r.kernel.org, Herbert Xu <herbert@...dor.apana.org.au>,
	linux-kernel@...r.kernel.org, Ingo Franzki <ifranzki@...ux.ibm.com>
Subject: Re: [PATCH] crypto: testmgr - reinstate kconfig support for fast
 tests only

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@...gle.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