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: <f0dc235e3d7bfa1f60cc01fd527da52024af54e0.camel@gmail.com>
Date: Thu, 15 May 2025 20:45:39 +0200
From: Klaus Kudielka <klaus.kudielka@...il.com>
To: Eric Biggers <ebiggers@...nel.org>, Herbert Xu
 <herbert@...dor.apana.org.au>
Cc: 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, 2025-05-15 at 11:21 -0700, Eric Biggers wrote:
> 
> 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

Probably it was only the massive amount of printk's which slowed the system down.

With the plain cryptodev tree I now see:

# modprobe marvell-cesa
# dmesg | tail
[    4.949108] mv88e6085 f1072004.mdio-mii:10 lan4: Link is Up - 1Gbps/Full - flow control rx/tx
[    4.949199] br0: port 2(lan4) entered blocking state
[    4.949210] br0: port 2(lan4) entered forwarding state
[   46.915547] marvell-cesa f1090000.crypto: CESA device successfully registered
[   47.077931] alg: skcipher: skipping comparison tests for mv-cbc-des3-ede because cbc(des3_ede-generic) is unavailable
[   47.096665] alg: skcipher: skipping comparison tests for mv-cbc-aes because cbc(aes-generic) is unavailable
[   47.103401] alg: skcipher: skipping comparison tests for mv-cbc-des because cbc(des-generic) is unavailable
[   47.121374] alg: skcipher: skipping comparison tests for mv-ecb-des because ecb(des-generic) is unavailable
[   47.133757] alg: skcipher: skipping comparison tests for mv-ecb-des3-ede because ecb(des3_ede-generic) is unavailable
[   47.138474] alg: skcipher: skipping comparison tests for mv-ecb-aes because ecb(aes-generic) is unavailable
# grep test /proc/crypto 
selftest     : passed
selftest     : passed
selftest     : passed
selftest     : passed
selftest     : passed
selftest     : passed
selftest     : passed
selftest     : passed
selftest     : passed
selftest     : passed
selftest     : passed
selftest     : passed
selftest     : passed

...and the failing marvell-cesa self-tests seem to have magically disappeared.
I now had five successful reboot / modprobe marvell-cesa in a row.

Best regards, Klaus