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

Message-ID: <ff7e706b7d4f7924c8a3e0d9c6418d4e@manjaro.org>
Date: Wed, 17 Jul 2024 05:14:22 +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>, Anand Moon <linux.amoon@...il.com>
Subject: Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

Hello Daniel,

On 2024-07-17 04:24, Daniel Golle wrote:
> On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
>> On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
>> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
>> 
>> I don't know if it means something, but I noticed that I have
>> ``Long run: 0`` with all my poor results,
>> while Chen-Yu had ``Long run: 1``.
>> 
>> Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
>> very poor result (100% failure):
>> https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6rB2S7jg+dnoX8hAoWg@mail.gmail.com/
> 
> The conclusions I draw from that rather ugly situation are:
>  - The hwrng should not be enabled by default, but it should by done
>    for each board on which it is known to work well.
>  - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
>    defined in DT for each board:
>    * introduce new 'rochchip,rng-sample-count' property
>    * read 'quality' property already used for timeriomem_rng
> 
> I will prepare a follow-up patch taking those conclusions into account.

Please note that Chen-Yu ran the tests on a board based on the RK3568,
while Diederik ran the tests on boards based on the RK3566.  The 
observed
difference in the test results suggests that something differs betwen
these two SoC variants, instead of having the actual boards contributing
something to the whole thing.

In other words, I think that enabling the HWRNG on per-board basis isn't
the right thing to do, but it should be enabled on per-SoC basis, after
enough testing is performed on the particular SoC.  The same applies to
defining any HWRNG properties in the DT.

If we really had to enable the HWRNG on per-board basis, that would mean
that some issues exist for certain SoC batches, affecting some boards.
AFAIK, the actual board design can't affect the operation of the HWRNG,
so any HWRNG issues associated with some boards can have their SoCs as
the only root cause.  Consequently, if any board experiences issues,
we should discard its SoC as having unreliable HWRNG, because another
sample of the same board, or a sample of some other board based on the
same SoC, may or may not experience the same issues.

I hope all this makes sense.

> Just for completeness, here my test result on the NanoPi R5C:
> root@...nWrt:~# cat /dev/hwrng | rngtest -c 1000
> rngtest 6.15
> Copyright (c) 2004 by Henrique de Moraes Holschuh
> This is free software; see the source for copying conditions.  There
> is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> 
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 875
> rngtest: FIPS 140-2 failures: 125
> rngtest: FIPS 140-2(2001-10-10) Monobit: 123
> rngtest: FIPS 140-2(2001-10-10) Poker: 5
> rngtest: FIPS 140-2(2001-10-10) Runs: 4
> rngtest: FIPS 140-2(2001-10-10) Long run: 0
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=85.171; avg=141.102; 
> max=4882812.500)Kibits/s
> rngtest: FIPS tests speed: (min=17.809; avg=19.494; max=60.169)Mibits/s
> rngtest: Program run time: 139628605 microseconds