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

[Eric Biggers]

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@xxxxxxxxxxx/

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