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: <DAJYOYMK9UJD.LB0N2L64FFA@cknow.org>
Date: Wed, 11 Jun 2025 21:47:27 +0200
From: "Diederik de Haas" <didi.debian@...ow.org>
To: "Eric Biggers" <ebiggers@...nel.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 9:04 PM CEST, Eric Biggers wrote:
> 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 (?).
>
> 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).

That is recent and there's at least 1 person I recognize as having
proper expertise in this matter ;-)

> 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

Another problem (IMO) is that a lot (?) of people (like myself) don't
(really) understand crypto and therefor rely on the description in the
Kconfig help text and make a choice based on that.
That's (one of) the reason(s) I was so happy with the clear text :-)

> throw untested and broken hardware drivers over the wall at users.  As long as

Only speaking for myself, my *assumption* is that crypto functionality
in hardware is/should be faster and would lessen the load on the CPU
(which with several SBCs seems really worthwhile).
But I don't have the knowledge to determine whether it's broken or not.
Unless there's a(n easy) tool for that (like 'rngtest' [1]).

[1] https://lore.kernel.org/linux-rockchip/6425788.NZdkxuyfQg@bagend/
resulting in f.e.
5afdb98dcc55 ("arm64: dts: rockchip: Describe why is HWRNG disabled in RK356x base dtsi")

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

Thanks for the additional info :-)

Diederik

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)