| 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
| ||
|
Message-ID: <faa0baebabd3c31adf1afa7efbbdf608@manjaro.org> Date: Wed, 24 Jul 2024 08:07:51 +0200 From: Dragan Simic <dsimic@...jaro.org> To: Diederik de Haas <didi.debian@...ow.org> Cc: Chen-Yu Tsai <wens@...nel.org>, Daniel Golle <daniel@...rotopia.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 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@...ow.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@...ow.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@...etab2:~# uname -a >> > > > > Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow >> > > > > (2024-04-24) aarch64 GNU/Linux >> > > > > >> > > > > root@...etab2:~# 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@...bian-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@...etab2:~# 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@...k-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@...k-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@...rtz64b:~# 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@...rtz64b:~# 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@...rtz64b:~# 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@...rtz64b:~# 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@...rtz64:~# 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@...rtz64:~# 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@...rtz64a:~# 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@...rtz64a:~# 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@...rtz64a:~# 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@...rtz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000 > ... > rngtest: FIPS 140-2 successes: 386 > > rngtest: FIPS 140-2 failures: 614 > > root@...rtz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000 > ... > rngtest: FIPS 140-2 successes: 356 > rngtest: FIPS 140-2 failures: 644 > > Quartz64-B: > root@...rtz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000 > ... > rngtest: FIPS 140-2 successes: 118 > rngtest: FIPS 140-2 failures: 882 > > root@...rtz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000 > ... > rngtest: FIPS 140-2 successes: 133 > rngtest: FIPS 140-2 failures: 867 > > root@...rtz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null > > root@...rtz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000 > ... > rngtest: FIPS 140-2 successes: 97 > rngtest: FIPS 140-2 failures: 903 > > root@...rtz64b:~# 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@...etab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000 > ... > rngtest: FIPS 140-2 successes: 705 > rngtest: FIPS 140-2 failures: 295 > > root@...etab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000 > ... > rngtest: FIPS 140-2 successes: 678 > rngtest: FIPS 140-2 failures: 322 > > root@...etab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null > > root@...etab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000 > ... > rngtest: FIPS 140-2 successes: 681 > rngtest: FIPS 140-2 failures: 319 > > root@...etab2:~# 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. :/
Powered by blists - more mailing lists