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] [day] [month] [year] [list]

Message-ID: <1287d1f4-893f-4ace-947a-f85c4e0ee69d@leemhuis.info>
Date: Wed, 13 Nov 2024 10:57:47 +0100
From: Thorsten Leemhuis <regressions@...mhuis.info>
To: Klaus Kudielka <klaus.kudielka@...il.com>,
 Herbert Xu <herbert@...dor.apana.org.au>
Cc: regressions@...ts.linux.dev, linux-kernel@...r.kernel.org,
 Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
 Boris Brezillon <bbrezillon@...nel.org>, Arnaud Ebalard <arno@...isbad.org>,
 Romain Perier <romain.perier@...e-electrons.com>
Subject: Re: [REGRESSION] alg: ahash: Several tests fail during boot on Turris
 Omnia

On 12.11.24 20:33, Klaus Kudielka wrote:
> On Wed, 2024-10-16 at 17:53 +0800, Herbert Xu wrote:
>> Alright, so next I'm going to try to make TDMA entirely single-
>> threaded and see if that fixes it.
> 
> Hi, since this was marked as "not worth tracking*,

FWIW, I was taken back and forth and then decided with going down that
route -- but I might be wrong with the assessment.

> here a summary of my understanding
> 
> - hardware: Turris Omnia, Marvell Armada 385 (same behaviour on 2 devices)
> - the crypto self-tests on the hash algorithms provided by the  Marvell CESA
>   driver fail randomly (1-5 failures in 90% of the boots, rarely without failure)
> - this is likely a bug in the driver, which had been hidden for a long time
> - it is now exposed by parallel invocation of self-tests, introduced in v6.12-rc1,
>   commit 37da5d0ffa ("crypto: api - Do not wait for tests during registration")
> - to be safe, the algorithms in question (6 in total) have been set to priority 0 in
>   commit e845d2399a ("crypto: marvell/cesa - Disable hash algorithms")
> - so, there should be no immediate harm by wrong hashes (at least in 6.12)

Yeah, that round about was my understanding as well, which is why I
decided it's for now not worth spending time keeping an eye on. Would be
something different if it would turn out that some practical use case
(and not just self-tests) that worked earlier now is suddenly affected.
Or if that "set to priority 0" would lead to a significant performance
regression (but given the brokenness of the driver it thus could be seen
as a good thing).

Ciao, Thorsten