linux-kernel - Re: [REGRESSION] alg: ahash: Several tests fail during boot on Turris Omnia

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: <aBoMSHEMYj6FbH8o@gondor.apana.org.au>
Date: Tue, 6 May 2025 21:19:04 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Klaus Kudielka <klaus.kudielka@...il.com>
Cc: 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@...e-electrons.com>
Subject: Re: [REGRESSION] alg: ahash: Several tests fail during boot on
 Turris Omnia

On Wed, Oct 16, 2024 at 12:27:30PM +0800, Herbert Xu wrote:
> On Tue, Oct 15, 2024 at 07:38:27PM +0200, Klaus Kudielka wrote:
> >
> > So, I applied the TDMA-disable patch, and I saw the same errors.
> > Then, I applied the printk patch on top of that, and here is the result.
> > 
> > Not sure, whether this makes any sense...
> 
> Interesting, I think this shows that the non-TDMA path doesn't
> work at all :)

So I'm looking at this driver again as part of my partial block
work to eliminate partial block handling from drivers.

I haven't figured out exactly what's wrong with tdma, although
the chaining IRQ completion handling looks a bit fragile in that
if something goes wrong it'll simply mark all queued requests as
complete, corrupting any requests that have not yet been sent to
the hardware.

However, I think I know what's wrong with the non-DMA path.  I
dug up the old mv_cesa driver and it's clear that it simply can't
handle zero-length final updates like a lot of other hardware drivers.
This matches with what you sent me where all the test vectors that
failed was test 0 which is a zero-length update.

There used to be a fallback path but during the move to tdma
that appears to have been lost.

So if you're still interested I can create some patches for you
to test.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt