linux-kernel - Re: [PATCH] crypto: marvell/cesa - Avoid empty transfer descriptor

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: <20250515182131.GC1411@quark>
Date: Thu, 15 May 2025 11:21:31 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Klaus Kudielka <klaus.kudielka@...il.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
	Corentin Labbe <clabbe.montjoie@...il.com>,
	regressions@...ts.linux.dev, linux-kernel@...r.kernel.org,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	Boris Brezillon <bbrezillon@...nel.org>,
	EBALARD Arnaud <Arnaud.Ebalard@....gouv.fr>,
	Romain Perier <romain.perier@...il.com>
Subject: Re: [PATCH] crypto: marvell/cesa - Avoid empty transfer descriptor

On Thu, May 15, 2025 at 07:53:03PM +0200, Klaus Kudielka wrote:
> On Wed, 2025-05-14 at 13:14 +0800, Herbert Xu wrote:
> > 
> > Sorry, should've mentioned that this goes on top of the current
> > cryptodev tree:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/log/
> > 
> 
> Okay, so now I have two printk patches on top of the current cryptodev tree.
> 
> I have enabled CRYPTO_SELFTESTS
> 
> - Three successful reboot / modprobe marvell-cesa. All self-tests passed.
> - But the whole self-tests sequence now take approx. 2 minutes, instead of 15 seconds with plain v6.15-rc5
> - And the journal gets huge. 24k lines. I am attaching a gzipped version, hope this works.
> 
> Best regards, Klaus

CRYPTO_SELFTESTS now enables the full set of crypto self-tests, which for the
past 6 years have been needed to be run anyway to properly validate the drivers;
just developers often forgot to enable them because they were under a separate
kconfig option that had a confusing name.  So the longer test time is expected.
It's unfortunate that it takes 2 minutes on the platform you're testing (on most
platforms it's much faster), but presumably that is still okay since it's just a
development option?  People shouldn't be expecting to run these tests in
production kernels.  (But even if they are for some reason, the test time also
remains configurable via kernel command-line options.)

- Eric