linux-kernel - Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

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: <97dfca058858d7a5d933ddf7a84dba61@manjaro.org>
Date: Thu, 01 Aug 2024 18:48:36 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Diederik de Haas <didi.debian@...ow.org>, Chen-Yu Tsai
 <wens@...nel.org>, linux-rockchip@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, Rob Herring <robh@...nel.org>, Conor
 Dooley <conor+dt@...nel.org>, linux-kernel@...r.kernel.org, Herbert Xu
 <herbert@...dor.apana.org.au>, Martin Kaiser <martin@...ser.cx>, Sascha
 Hauer <s.hauer@...gutronix.de>, Sebastian Reichel
 <sebastian.reichel@...labora.com>, Ard Biesheuvel <ardb@...nel.org>,
 Uwe Kleine-König <ukleinek@...ian.org>,
 devicetree@...r.kernel.org, linux-crypto@...r.kernel.org, Philipp Zabel
 <p.zabel@...gutronix.de>, Olivia Mackall <olivia@...enic.com>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, Aurelien Jarno <aurelien@...el32.net>, Heiko
 Stuebner <heiko@...ech.de>
Subject: Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

Hello Daniel,

On 2024-07-30 01:18, Daniel Golle wrote:
> On Wed, Jul 24, 2024 at 08:07:51AM +0200, Dragan Simic wrote:
>> Thanks a lot for the testing.  Though, such wildly different test 
>> results
>> can, regrettably, lead to only one conclusion:  the HWRNG found in 
>> RK3566
>> is unusable. :/
> 
> The results on RK3568 look much better and the series right now also
> only enabled the RNG on RK3568 systems. However, we have only seen few
> boards with RK3568 up to now, and I only got a couple of NanoPi R5C
> here to test, all with good hwrng results.
> 
> Do you think it would be agreeable to only enable the HWRNG for RK3568
> as suggested in this series? Or are we expecting quality to also vary
> as much as it (sadly) does for RK3566?

I'm a bit late to the party, sorry for that.  The test results so far
show that the HWRNG in RK3566 simply cannot be relied upon, but the test
results also show that the RK3568's HWRNG seems fine.  I'm wondering 
why,
but until we bump into a sample of RK3568 whose HWRNG performs badly,
I'd say that enabling the HWRNG on RK3568 only is safe.

Of course, as other people already noted, the HWRNG should be defined in
rk356x.dtsi, because it does exist in both SoC variants, but should be
enabled in rk3568.dtsi only.  As already noted, describing it as broken
on RK3566 in rk356x.dtsi should also be good.