All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Diederik de Haas" <didi.debian@cknow.org>
To: "Eric Biggers" <ebiggers@kernel.org>
Cc: <linux-crypto@vger.kernel.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	<linux-kernel@vger.kernel.org>,
	"Ingo Franzki" <ifranzki@linux.ibm.com>
Subject: Re: [PATCH] crypto: testmgr - reinstate kconfig support for fast tests only
Date: Wed, 11 Jun 2025 21:47:27 +0200	[thread overview]
Message-ID: <DAJYOYMK9UJD.LB0N2L64FFA@cknow.org> (raw)
In-Reply-To: <20250611190458.GA4097002@google.com>

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2025-06-11 19:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-11 17:55 [PATCH] crypto: testmgr - reinstate kconfig support for fast tests only Eric Biggers
2025-06-11 18:53 ` Diederik de Haas
2025-06-11 19:04   ` Eric Biggers
2025-06-11 19:47     ` Diederik de Haas [this message]
2025-06-11 20:14       ` Eric Biggers
2025-06-12  5:55 ` Herbert Xu
2025-06-12  6:09   ` Eric Biggers
2025-06-12  9:03     ` Herbert Xu
2025-06-12 17:20       ` Eric Biggers

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=DAJYOYMK9UJD.LB0N2L64FFA@cknow.org \
    --to=didi.debian@cknow.org \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=ifranzki@linux.ibm.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@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.