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: <20250611201408.GB4097002@google.com>
Date: Wed, 11 Jun 2025 20:14:08 +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 09:47:27PM +0200, Diederik de Haas wrote:
> 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 ;-)

FWIW, here's an example from just today where the crypto self-tests prevented a
buggy driver from being used in Debian:
https://lore.kernel.org/linux-crypto/20250611101750.6839-1-AlanSong-oc@zhaoxin.com/

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

Often the hardware offloads are actually slower.  They require sending the CPU
an interrupt once the operation is done, which has a lot of overhead.  They also
tend to be optimized for throughput rather than latency, and only provide good
throughput when given a large number of concurrent requests.

Inline encryption does actually work, but that is a separate type of accelerator
and not what we're talking about here.

- Eric