devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dragan Simic <dsimic@manjaro.org>
To: Diederik de Haas <didi.debian@cknow.org>
Cc: "Chen-Yu Tsai" <wens@kernel.org>,
	"Daniel Golle" <daniel@makrotopia.org>,
	linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	"Rob Herring" <robh@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	linux-kernel@vger.kernel.org,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Martin Kaiser" <martin@kaiser.cx>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Sebastian Reichel" <sebastian.reichel@collabora.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Uwe Kleine-König" <ukleinek@debian.org>,
	devicetree@vger.kernel.org, linux-crypto@vger.kernel.org,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Olivia Mackall" <olivia@selenic.com>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"Heiko Stuebner" <heiko@sntech.de>
Subject: Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568
Date: Wed, 24 Jul 2024 08:07:51 +0200	[thread overview]
Message-ID: <faa0baebabd3c31adf1afa7efbbdf608@manjaro.org> (raw)
In-Reply-To: <4406786.zLnsZ2vfAB@bagend>

Hello Diederik and Chen-Yu,

On 2024-07-22 21:03, Diederik de Haas wrote:
> On Monday, 22 July 2024 19:57:05 CEST Chen-Yu Tsai wrote:
>> On Wed, Jul 17, 2024 at 12:54 AM Diederik de Haas 
>> <didi.debian@cknow.org>
> wrote:
>> > On Tuesday, 16 July 2024 17:18:48 CEST Chen-Yu Tsai wrote:
>> > > On Jul 16, 2024 at 10:13 PM Diederik de Haas <didi.debian@cknow.org>
> wrote:
>> > > > On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
>> > > > > For shits and giggles, I tried it on my PineTab2 too (also rk3566):
>> > > > >
>> > > > > ===========================================================
>> > > > > root@pinetab2:~# uname -a
>> > > > > Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
>> > > > > (2024-04-24) aarch64 GNU/Linux
>> > > > >
>> > > > > root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
>> > > > > 1+0 records in
>> > > > > 1+0 records out
>> > > > > 100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
>> > > > >
>> > > > > root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
>> > > > > rngtest 5
>> > > > > ...
>> > > > > rngtest: starting FIPS tests...
>> > > > > rngtest: bits received from input: 20000032
>> > > > > rngtest: FIPS 140-2 successes: 730
>> > > > > rngtest: FIPS 140-2 failures: 270
>> > > > > ===========================================================
>> > > > >
>> > > > > That's looking quite a lot better ... and I have no idea why.
>> > > > >
>> > > > > The Q64-A is used as headless server and the PineTab2 is not,
>> > > > > but I connected to both over SSH and they were freshly booted
>> > > > > into, thus I haven't actually/normally used the PT2 since boot.
>> > > >
>> > > > I did freshly install rng-tools5 package before running the test, so
>> > > > I rebooted again to make sure that wasn't a factor:
>> > > >
>> > > > ===========================================================
>> > > > root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
>> > > > rngtest 5
>> > > > ...
>> > > > rngtest: starting FIPS tests...
>> > > > rngtest: bits received from input: 20000032
>> > > > rngtest: FIPS 140-2 successes: 704
>> > > > rngtest: FIPS 140-2 failures: 296
>> > > > ===========================================================
>> > > >
>> > > > So that 704/296 vs 730/270 in the previous run on the PT2.
>> > > >
>> > > On my Rock 3A:
>> > >
>> > > wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
>> > > rngtest 5
>> > > ...
>> > > rngtest: starting FIPS tests...
>> > > rngtest: bits received from input: 20000032
>> > > rngtest: FIPS 140-2 successes: 992
>> > > rngtest: FIPS 140-2 failures: 8
>> > >
>> > > wens@rock-3a:~$ uname -a
>> > > Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
>> > > Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux
>> >
>> > I wondered if ``dd if=/dev/hwrng bs=100000 count=1 > /dev/null`` before
>> > the actual test run made a difference.
>> > Tried it on my Quartz64 Model A: no
>> >
>> > Then I tried it on my Quartz64 Model B:
>> >
>> > root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
>> > rngtest 5
>> > ...
>> > rngtest: starting FIPS tests...
>> > rngtest: bits received from input: 20000032
>> > rngtest: FIPS 140-2 successes: 120
>> > rngtest: FIPS 140-2 failures: 880
>> >
>> > root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
>> > 1+0 records in
>> > 1+0 records out
>> > 100000 bytes (100 kB, 98 KiB) copied, 5.71466 s, 17.5 kB/s
>> >
>> > root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
>> > rngtest 5
>> > ...
>> > rngtest: starting FIPS tests...
>> > rngtest: bits received from input: 20000032
>> > rngtest: FIPS 140-2 successes: 104
>> > rngtest: FIPS 140-2 failures: 896
>> >
>> > root@quartz64b:~# uname -a
>> > Linux quartz64b 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
>> > (2024-04-24) aarch64 GNU/Linux>
>> > :-O
>> 
>> I pulled out my Quartz64 model B, and the results seem better than 
>> yours.
>> 
>> root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
>> rngtest 5
>> ...
>> rngtest: starting FIPS tests...
>> rngtest: bits received from input: 20000032
>> rngtest: FIPS 140-2 successes: 859
>> rngtest: FIPS 140-2 failures: 141
>> root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
>> rngtest 5
>> ...
>> rngtest: starting FIPS tests...
>> rngtest: bits received from input: 20000032
>> rngtest: FIPS 140-2 successes: 843
>> rngtest: FIPS 140-2 failures: 157
> 
> I noticed you used ``dd`` instead of ``cat``, so I tried again ...
> 
> Quartz64-A:
> root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> rngtest 5
> ...
> rngtest: starting FIPS tests...
> 
> rngtest: bits received from input: 20000032
> 
> rngtest: FIPS 140-2 successes: 411
> 
> rngtest: FIPS 140-2 failures: 589
> 
> root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 391
> rngtest: FIPS 140-2 failures: 609
> 
> root@quartz64a:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> 1+0 records in
> 1+0 records out
> 100000 bytes (100 kB, 98 KiB) copied, 5.66202 s, 17.7 kB/s
> 
> root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 386
> 
> rngtest: FIPS 140-2 failures: 614
> 
> root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 356
> rngtest: FIPS 140-2 failures: 644
> 
> Quartz64-B:
> root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 118
> rngtest: FIPS 140-2 failures: 882
> 
> root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 133
> rngtest: FIPS 140-2 failures: 867
> 
> root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> 
> root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 97
> rngtest: FIPS 140-2 failures: 903
> 
> root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 130
> rngtest: FIPS 140-2 failures: 870
> 
> And lastly on PineTab2:
> root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 705
> rngtest: FIPS 140-2 failures: 295
> 
> root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 678
> rngtest: FIPS 140-2 failures: 322
> 
> root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> 
> root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 681
> rngtest: FIPS 140-2 failures: 319
> 
> root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 669
> rngtest: FIPS 140-2 failures: 331
> 
> 
> So my Q64-B tests are consistently MUCH worse then your Q64-B tests ...
> This seems BAD to me, now that we even have completely different 
> results per
> device of the EXACT same model?!? Hardware revision may be different (I 
> have a
> v1.4), but it seems rather pointless to go into that direction.
> 
> It then also seems rather pointless to try it with different parameters 
> if the
> results on the same SBC model can vary this much.

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. :/

  reply	other threads:[~2024-07-24  6:07 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-14 15:15 [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568 Daniel Golle
2024-07-14 15:15 ` [PATCH v7 1/3] dt-bindings: rng: Add Rockchip RK3568 TRNG Daniel Golle
2024-07-14 15:16 ` [PATCH v7 2/3] hwrng: add hwrng driver for Rockchip RK3568 SoC Daniel Golle
2024-07-15 19:47   ` Martin Kaiser
2024-07-21  0:26   ` Jason A. Donenfeld
2024-07-14 15:18 ` [PATCH v7 3/3] arm64: dts: rockchip: add DT entry for RNG to RK356x Daniel Golle
2024-07-14 18:09 ` [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568 Chen-Yu Tsai
2024-07-16 12:34 ` Diederik de Haas
2024-07-16 13:27   ` Daniel Golle
2024-07-16 13:59     ` Diederik de Haas
2024-07-16 14:13       ` Diederik de Haas
2024-07-16 15:18         ` Chen-Yu Tsai
2024-07-16 16:53           ` Diederik de Haas
2024-07-16 17:19             ` Diederik de Haas
2024-07-17  2:24               ` Daniel Golle
2024-07-17  2:58                 ` Chen-Yu Tsai
2024-07-17  3:34                   ` Dragan Simic
2024-07-17  5:06                   ` Anand Moon
2024-07-17  5:18                     ` Dragan Simic
2024-07-17  8:22                   ` Diederik de Haas
2024-07-17  8:31                     ` Dragan Simic
2024-07-17  8:38                     ` Chen-Yu Tsai
2024-07-17  8:49                       ` Diederik de Haas
2024-07-17 10:44                     ` Daniel Golle
2024-07-17  3:14                 ` Dragan Simic
2024-07-22 17:57             ` Chen-Yu Tsai
2024-07-22 19:03               ` Diederik de Haas
2024-07-24  6:07                 ` Dragan Simic [this message]
2024-07-29 23:18                   ` Daniel Golle
2024-07-30  9:03                     ` Diederik de Haas
2024-07-30 10:36                       ` Heiko Stübner
2024-07-30 12:08                         ` Chen-Yu Tsai
2024-08-01 16:48                     ` Dragan Simic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=faa0baebabd3c31adf1afa7efbbdf608@manjaro.org \
    --to=dsimic@manjaro.org \
    --cc=ardb@kernel.org \
    --cc=aurelien@aurel32.net \
    --cc=conor+dt@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=devicetree@vger.kernel.org \
    --cc=didi.debian@cknow.org \
    --cc=heiko@sntech.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=martin@kaiser.cx \
    --cc=olivia@selenic.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=sebastian.reichel@collabora.com \
    --cc=ukleinek@debian.org \
    --cc=wens@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).