| Message ID | cover.1720969799.git.daniel@makrotopia.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | hwrng: add hwrng support for Rockchip RK3568 | expand |
On Sun, Jul 14, 2024 at 11:16 PM Daniel Golle <daniel@makrotopia.org> wrote: > > Rockchip SoCs used to have a random number generator as part of their > crypto device. > > However newer Rockchip SoCs like the RK3568 have an independent True > Random Number Generator device. This patchset adds a driver for it and > enables it in the device tree. > > Tested on FriendlyARM NanoPi R5C. > > v6 -> v7: > * Patch 1: unchanged > > * Patch 2: bring back rk_rng_write_ctl() > - bring back rk_rng_write_ctl() with improved comment to describe > the hardware. > > * Patch 3: unchaned > > v5 -> v6: > * Patch 1: unchanged > > * Patch 2: get rid of #ifdef > - use if (IS_ENABLED(...)) { ... }instead of #ifdef inside functions > - use __maybe_unused for functions previously enclosed by #ifdef'ery > > * Patch 3: unchanged > > v4 -> v5: > * Patch 1: always use RK3568 name > - use full RK3568 name in patch description > - add RK3568 to title in binding > > * Patch 2: full name and cosmetics > - also always mention RK3568 as there may be other RNG in other > (future) Rockchip SoCs > - remove debug output on successful probe > - use MODULE_AUTHOR several times instead of single comma-separated > > * Patch 3: unchanged > > v3 -> v4: > * Patch 1: minor corrections > - fix Rokchip -> Rockchip typo > - change commit title as requested > > * Patch 2: improved error handling and resource management > - Always use writel() instead of writel_relaxed() > - Use pm_runtime_resume_and_get > - Correctly return error code in rk_rng_read() > - Make use of devm_reset_control_array_get_exclusive > - Use devm_pm_runtime_enable and there by get rid of rk_rng_remove() > > * Patch 3: > - Move node to conform with ordering by address > > v2 -> v3: patch adopted by Daniel Golle > * Patch 1: address comments of Krzysztof Kozlowski, add MAINTAINERS > - improved description > - meaningful clock-names > - add entry in MAINTAINERS files > > * Patch 2: numerous code-style improvements > - drop misleading rk_rng_write_ctl(), simplify I/O writes > - drop unused TRNG_RNG_DOUT_[1-7] macros > - handle error handling for pm_runtime_get_sync() > - use memcpy_fromio() instead of open coding for-loop > - some minor white-spaces fixes > > * Patch 3: > - use clock-names as defined in dt-bindings > > v1 -> v2: > * Patch 1: fix issues reported by Rob Herring and Krzysztof Kozlowski: > - Rename rockchip-rng.yaml into rockchip,rk3568-rng.yaml > - Fix binding title and description > - Fix compatible property > - Rename clocks and add the corresponding descriptions > - Drop reset-names > - Add a bus definition with #address-cells and #size-cells to the > example. > > * Patch 2: fix issue reported by kernel test robot <lkp@intel.com> > - Do not read the random registers as big endian, looking at the > RK3568 TRM this is actually not needed. This fixes a sparse > warning. > > * Patch 3: unchanged > > > Aurelien Jarno (3): > dt-bindings: rng: Add Rockchip RK3568 TRNG > hwrng: add hwrng driver for Rockchip RK3568 SoC > arm64: dts: rockchip: add DT entry for RNG to RK356x Tested-by: Chen-Yu Tsai <wens@csie.org> > .../bindings/rng/rockchip,rk3568-rng.yaml | 61 +++++ > MAINTAINERS | 7 + > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 9 + > drivers/char/hw_random/Kconfig | 14 ++ > drivers/char/hw_random/Makefile | 1 + > drivers/char/hw_random/rockchip-rng.c | 227 ++++++++++++++++++ > 6 files changed, 319 insertions(+) > create mode 100644 Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml > create mode 100644 drivers/char/hw_random/rockchip-rng.c > > -- > 2.45.2
On Sunday, 14 July 2024 17:15:35 CEST Daniel Golle wrote: > Rockchip SoCs used to have a random number generator as part of their > crypto device. > > However newer Rockchip SoCs like the RK3568 have an independent True > Random Number Generator device. This patchset adds a driver for it and > enables it in the device tree. > > Tested on FriendlyARM NanoPi R5C. > > ... > > Aurelien Jarno (3): > dt-bindings: rng: Add Rockchip RK3568 TRNG > hwrng: add hwrng driver for Rockchip RK3568 SoC > arm64: dts: rockchip: add DT entry for RNG to RK356x > > .../bindings/rng/rockchip,rk3568-rng.yaml | 61 +++++ > MAINTAINERS | 7 + > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 9 + > drivers/char/hw_random/Kconfig | 14 ++ > drivers/char/hw_random/Makefile | 1 + > drivers/char/hw_random/rockchip-rng.c | 227 ++++++++++++++++++ > 6 files changed, 319 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml create mode > 100644 drivers/char/hw_random/rockchip-rng.c I just did the following test on my Quartz64 Model A running kernel 6.10 + a number of patches, including this one: =============================================================== 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.64507 s, 17.7 kB/s root@quartz64a:~# cat /dev/hwrng | rngtest -c 1000 rngtest 5 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: 362 rngtest: FIPS 140-2 failures: 638 rngtest: FIPS 140-2(2001-10-10) Monobit: 634 rngtest: FIPS 140-2(2001-10-10) Poker: 106 rngtest: FIPS 140-2(2001-10-10) Runs: 43 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=2.638; avg=139.351; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=21.169; avg=36.158; max=68.610)Mibits/s rngtest: Program run time: 148109761 microseconds =============================================================== That's almost twice as many failures as successes ...
Hi Diederik, On Tue, Jul 16, 2024 at 02:34:40PM +0200, Diederik de Haas wrote: > [...] > rngtest: starting FIPS tests... > rngtest: bits received from input: 20000032 > rngtest: FIPS 140-2 successes: 362 > rngtest: FIPS 140-2 failures: 638 > rngtest: FIPS 140-2(2001-10-10) Monobit: 634 > rngtest: FIPS 140-2(2001-10-10) Poker: 106 > rngtest: FIPS 140-2(2001-10-10) Runs: 43 > 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=2.638; avg=139.351; max=9765625.000)Kibits/s > rngtest: FIPS tests speed: (min=21.169; avg=36.158; max=68.610)Mibits/s > rngtest: Program run time: 148109761 microseconds > =============================================================== > > That's almost twice as many failures as successes ... That's bad news, and apparently different from Aurelien's initial testing of the driver. Can you try if the result is also that bad when using his version of the driver: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20221128184718.1963353-3-aurelien@aurel32.net/ If so, we can try to increase RK_RNG_SAMPLE_CNT, and we may need different values depending on the SoC...
Hi Daniel, On Tuesday, 16 July 2024 15:27:33 CEST Daniel Golle wrote: > On Tue, Jul 16, 2024 at 02:34:40PM +0200, Diederik de Haas wrote: > > [...] > > rngtest: starting FIPS tests... > > rngtest: bits received from input: 20000032 > > rngtest: FIPS 140-2 successes: 362 > > rngtest: FIPS 140-2 failures: 638 > > rngtest: FIPS 140-2(2001-10-10) Monobit: 634 > > rngtest: FIPS 140-2(2001-10-10) Poker: 106 > > rngtest: FIPS 140-2(2001-10-10) Runs: 43 > > 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=2.638; avg=139.351; > > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=21.169; > > avg=36.158; max=68.610)Mibits/s rngtest: Program run time: 148109761 > > microseconds > > =============================================================== > > > > That's almost twice as many failures as successes ... > > That's bad news, and apparently different from Aurelien's initial > testing of the driver. > > Can you try if the result is also that bad when using his version of > the driver: > > https://patchwork.kernel.org/project/linux-arm-kernel/patch/20221128184718.1 > 963353-3-aurelien@aurel32.net/ > > If so, we can try to increase RK_RNG_SAMPLE_CNT, and we may need > different values depending on the SoC... I had been using a rebased version (with fixed includes) of Aurelien's patch set and I switched to 'your' version somewhere in the 6.10-rcX cycle, but I didn't record exactly when. But I had a 6.9.2 kernel of which I'm confident has that rebased patch set: =========================================================== root@quartz64a:~# uname -a Linux quartz64a 6.9+unreleased-arm64 #1 SMP Debian 6.9.2-1~cknow (2024-04-24) aarch64 GNU/Linux 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.6801 s, 17.6 kB/s root@quartz64a:~# cat /dev/hwrng | rngtest -c 1000 rngtest 5 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: 361 rngtest: FIPS 140-2 failures: 639 rngtest: FIPS 140-2(2001-10-10) Monobit: 637 rngtest: FIPS 140-2(2001-10-10) Poker: 115 rngtest: FIPS 140-2(2001-10-10) Runs: 34 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=2.603; avg=137.548; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=21.479; avg=37.156; max=89.547)Mibits/s rngtest: Program run time: 149992805 microseconds =========================================================== So that's consistent(ly bad). 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 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: 730 rngtest: FIPS 140-2 failures: 270 rngtest: FIPS 140-2(2001-10-10) Monobit: 266 rngtest: FIPS 140-2(2001-10-10) Poker: 23 rngtest: FIPS 140-2(2001-10-10) Runs: 9 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=2.615; avg=137.889; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643; avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336 microseconds =========================================================== 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. HTH, Diederik
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 > 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: 730 > rngtest: FIPS 140-2 failures: 270 > rngtest: FIPS 140-2(2001-10-10) Monobit: 266 > rngtest: FIPS 140-2(2001-10-10) Poker: 23 > rngtest: FIPS 140-2(2001-10-10) Runs: 9 > 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=2.615; avg=137.889; > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643; > avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336 > microseconds > =========================================================== > > 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 rngtest: FIPS 140-2(2001-10-10) Monobit: 293 rngtest: FIPS 140-2(2001-10-10) Poker: 32 rngtest: FIPS 140-2(2001-10-10) Runs: 10 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=2.612; avg=137.833; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.391; avg=34.416; max=68.364)Mibits/s rngtest: Program run time: 149736205 microseconds =========================================================== So that 704/296 vs 730/270 in the previous run on the PT2. In case it helps: =========================================================== root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_* /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng /sys/devices/virtual/misc/hw_random/rng_quality:900 /sys/devices/virtual/misc/hw_random/rng_selected:0 root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_* /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng /sys/devices/virtual/misc/hw_random/rng_quality:900 /sys/devices/virtual/misc/hw_random/rng_selected:0 =========================================================== Cheers, Diederik
On Tue, 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 > > 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: 730 > > rngtest: FIPS 140-2 failures: 270 > > rngtest: FIPS 140-2(2001-10-10) Monobit: 266 > > rngtest: FIPS 140-2(2001-10-10) Poker: 23 > > rngtest: FIPS 140-2(2001-10-10) Runs: 9 > > 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=2.615; avg=137.889; > > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643; > > avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336 > > microseconds > > =========================================================== > > > > 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 > rngtest: FIPS 140-2(2001-10-10) Monobit: 293 > rngtest: FIPS 140-2(2001-10-10) Poker: 32 > rngtest: FIPS 140-2(2001-10-10) Runs: 10 > 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=2.612; avg=137.833; max=9765625.000)Kibits/s > rngtest: FIPS tests speed: (min=24.391; avg=34.416; max=68.364)Mibits/s > rngtest: Program run time: 149736205 microseconds > =========================================================== > > So that 704/296 vs 730/270 in the previous run on the PT2. > > In case it helps: > =========================================================== > root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_* > /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng > /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng > /sys/devices/virtual/misc/hw_random/rng_quality:900 > /sys/devices/virtual/misc/hw_random/rng_selected:0 > > root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_* > /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng > /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng > /sys/devices/virtual/misc/hw_random/rng_quality:900 > /sys/devices/virtual/misc/hw_random/rng_selected:0 > =========================================================== On my Rock 3A: wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000 rngtest 5 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: 992 rngtest: FIPS 140-2 failures: 8 rngtest: FIPS 140-2(2001-10-10) Monobit: 7 rngtest: FIPS 140-2(2001-10-10) Poker: 0 rngtest: FIPS 140-2(2001-10-10) Runs: 0 rngtest: FIPS 140-2(2001-10-10) Long run: 1 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=2.658; avg=140.067; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=26.751; avg=34.901; max=65.320)Mibits/s rngtest: Program run time: 147367594 microseconds 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 ChenYu
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 > > > 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: 730 > > > rngtest: FIPS 140-2 failures: 270 > > > rngtest: FIPS 140-2(2001-10-10) Monobit: 266 > > > rngtest: FIPS 140-2(2001-10-10) Poker: 23 > > > rngtest: FIPS 140-2(2001-10-10) Runs: 9 > > > 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=2.615; avg=137.889; > > > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643; > > > avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336 > > > microseconds > > > =========================================================== > > > > > > 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 > > rngtest: FIPS 140-2(2001-10-10) Monobit: 293 > > rngtest: FIPS 140-2(2001-10-10) Poker: 32 > > rngtest: FIPS 140-2(2001-10-10) Runs: 10 > > 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=2.612; avg=137.833; > > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.391; > > avg=34.416; max=68.364)Mibits/s rngtest: Program run time: 149736205 > > microseconds > > =========================================================== > > > > So that 704/296 vs 730/270 in the previous run on the PT2. > > > > In case it helps: > > =========================================================== > > root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_* > > /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng > > /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng > > /sys/devices/virtual/misc/hw_random/rng_quality:900 > > /sys/devices/virtual/misc/hw_random/rng_selected:0 > > > > root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_* > > /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng > > /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng > > /sys/devices/virtual/misc/hw_random/rng_quality:900 > > /sys/devices/virtual/misc/hw_random/rng_selected:0 > > =========================================================== > > On my Rock 3A: > > wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000 > rngtest 5 > 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: 992 > rngtest: FIPS 140-2 failures: 8 > rngtest: FIPS 140-2(2001-10-10) Monobit: 7 > rngtest: FIPS 140-2(2001-10-10) Poker: 0 > rngtest: FIPS 140-2(2001-10-10) Runs: 0 > rngtest: FIPS 140-2(2001-10-10) Long run: 1 > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 > rngtest: input channel speed: (min=2.658; avg=140.067; > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=26.751; > avg=34.901; max=65.320)Mibits/s rngtest: Program run time: 147367594 > microseconds > > 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 rngtest: FIPS 140-2(2001-10-10) Monobit: 879 rngtest: FIPS 140-2(2001-10-10) Poker: 332 rngtest: FIPS 140-2(2001-10-10) Runs: 91 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=2.615; avg=138.117; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=20.777; avg=34.535; max=68.857)Mibits/s rngtest: Program run time: 149461754 microseconds 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 rngtest: FIPS 140-2(2001-10-10) Monobit: 892 rngtest: FIPS 140-2(2001-10-10) Poker: 335 rngtest: FIPS 140-2(2001-10-10) Runs: 79 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=2.613; avg=138.098; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=20.465; avg=34.587; max=69.107)Mibits/s rngtest: Program run time: 149475187 microseconds root@quartz64b:~# uname -a Linux quartz64b 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24) aarch64 GNU/Linux :-O
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/
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. Just for completeness, here my test result on the NanoPi R5C: root@OpenWrt:~# 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
On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> 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. > > Just for completeness, here my test result on the NanoPi R5C: > root@OpenWrt:~# 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 I doubt this is per-board. The RNG is inside the SoC, so it could be a chip quality thing. On the RK3399 we also saw wildly varying results. ChenYu
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@OpenWrt:~# 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
Hello Chen-Yu, On 2024-07-17 04:58, Chen-Yu Tsai wrote: > On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> > 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. >> >> Just for completeness, here my test result on the NanoPi R5C: >> root@OpenWrt:~# 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 > > I doubt this is per-board. The RNG is inside the SoC, so it > could be a chip quality thing. Totally agreed. I see no way how a board design could affect the HWRNGs built into Rockchip SoCs. I even checked the RK3399 and RK3566 Hardware Design Guides to be extra sure. > On the RK3399 we also saw wildly varying results. In my opinion, that qualifies the RK3399's HWRNG as unsuitable for general use. Having a HWRNG that fails to pass the tests on _some_ units is simply not acceptable from the security standpoint.
Hi All, On Wed, 17 Jul 2024 at 08:29, Chen-Yu Tsai <wens@kernel.org> wrote: > > On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> 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. > > > > Just for completeness, here my test result on the NanoPi R5C: > > root@OpenWrt:~# 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 > > I doubt this is per-board. The RNG is inside the SoC, so it could be a chip > quality thing. On the RK3399 we also saw wildly varying results. > I feel the latest rng-tool only supports Intel platform x86_64 and i386. It has no proper support for Arm64 and Armv7 It is heavily modified for the X86 platform so it's not suitable for testing on other platforms. If we enable HWRNG on all the Rockchip platforms it will be better. [1] https://github.com/nhorman/rng-tools > ChenYu Thanks -Anand
Hello Anand, On 2024-07-17 07:06, Anand Moon wrote: > On Wed, 17 Jul 2024 at 08:29, Chen-Yu Tsai <wens@kernel.org> wrote: >> >> On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> >> 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. >> > >> > Just for completeness, here my test result on the NanoPi R5C: >> > root@OpenWrt:~# 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 >> >> I doubt this is per-board. The RNG is inside the SoC, so it could be a >> chip >> quality thing. On the RK3399 we also saw wildly varying results. >> > I feel the latest rng-tool only supports Intel platform x86_64 and > i386. > It has no proper support for Arm64 and Armv7 > It is heavily modified for the X86 platform > so it's not suitable for testing on other platforms. > > If we enable HWRNG on all the Rockchip platforms it will be better. > > [1] https://github.com/nhorman/rng-tools I don't see what could be tweaked in rngtest(1) to support any platform better than the other, and still remain a valid test. It just applies certain FIPS test(s) to the random data obtained from /dev/hwrng or some other source, and if that testing is tweaked in any way, then the test results aren't valid on any platform. In other words, perhaps the other components of rng-tools are tweaked to support "mainstream" platforms better, but rngtest(1) simply must not be tweaked in any way.
On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote: > On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> 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/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6 > > > rB2S7jg+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. > > > > Just for completeness, here my test result on the NanoPi R5C: > > root@OpenWrt:~# 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 > > I doubt this is per-board. The RNG is inside the SoC, so it could be a chip > quality thing. I agree with ChenYu (and others) that this is isn't a per-board level thing. I'd even go further: 's/I doubt/It can't be that/' (for the same reason though; this is inside the SoC). Before I saw these latest emails, I was going to suggest: 1. Enable it only on RK3568 for now. I would be fine if this would be accepted by the maintainer 2. Ask that you make a special version (for me) where I could play with the params without having to compile a new kernel for each variant (it generally takes me more then 24h on my Q64-A). Either through kernel module properties or properties defined in the DeviceTree is fine with me. 3. Based on the results make a choice to not enable it on rk3566 at all or (indeed) introduce DT properties to configure it differently per SoC. 4. Hope/Ask for more test results > On the RK3399 we also saw wildly varying results. On my Rock64('s) (RK3328) it doesn't work at all: ``` root@cs21:~# cat /dev/hwrng | rngtest -c 1000 rngtest 5 ... rngtest: starting FIPS tests... cat: /dev/hwrng: No such device rngtest: entropy source drained ``` Cheers, Diederik
Hello Diederik, On 2024-07-17 10:22, Diederik de Haas wrote: > On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote: >> On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> >> 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/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6 >> > > rB2S7jg+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. >> > >> > Just for completeness, here my test result on the NanoPi R5C: >> > root@OpenWrt:~# 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 >> >> I doubt this is per-board. The RNG is inside the SoC, so it could be a >> chip >> quality thing. > > I agree with ChenYu (and others) that this is isn't a per-board level > thing. > I'd even go further: 's/I doubt/It can't be that/' (for the same reason > though; this is inside the SoC). > > Before I saw these latest emails, I was going to suggest: > 1. Enable it only on RK3568 for now. I would be fine if this would be > accepted > by the maintainer I think we need more testing on more units of the RK3568 SoC, simply because the HWRNG may work badly on some units. I know that it sucks, but we basically need just one "bad apple" to mark an SoC as having an unreliable HWRNG, which is IMHO the only right thing to do. Of course, unless we can prove that tweaking the HWRNG knobs makes such "bad apples" work well. > 2. Ask that you make a special version (for me) where I could play with > the > params without having to compile a new kernel for each variant (it > generally > takes me more then 24h on my Q64-A). Either through kernel module > properties > or properties defined in the DeviceTree is fine with me. > > 3. Based on the results make a choice to not enable it on rk3566 at > all or > (indeed) introduce DT properties to configure it differently per SoC. See above; unfortunately, we already have some "bad RK3566 apples". > 4. Hope/Ask for more test results > >> On the RK3399 we also saw wildly varying results. > > On my Rock64('s) (RK3328) it doesn't work at all: > > ``` > root@cs21:~# cat /dev/hwrng | rngtest -c 1000 > rngtest 5 > ... > rngtest: starting FIPS tests... > cat: /dev/hwrng: No such device > rngtest: entropy source drained > ```
On Wed, Jul 17, 2024 at 4:22 PM Diederik de Haas <didi.debian@cknow.org> wrote: > > On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote: > > On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> 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/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6 > > > > rB2S7jg+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. > > > > > > Just for completeness, here my test result on the NanoPi R5C: > > > root@OpenWrt:~# 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 > > > > I doubt this is per-board. The RNG is inside the SoC, so it could be a chip > > quality thing. > > I agree with ChenYu (and others) that this is isn't a per-board level thing. > I'd even go further: 's/I doubt/It can't be that/' (for the same reason > though; this is inside the SoC). > > Before I saw these latest emails, I was going to suggest: > 1. Enable it only on RK3568 for now. I would be fine if this would be accepted > by the maintainer > > 2. Ask that you make a special version (for me) where I could play with the > params without having to compile a new kernel for each variant (it generally > takes me more then 24h on my Q64-A). Either through kernel module properties > or properties defined in the DeviceTree is fine with me. > > 3. Based on the results make a choice to not enable it on rk3566 at all or > (indeed) introduce DT properties to configure it differently per SoC. > > 4. Hope/Ask for more test results > > > On the RK3399 we also saw wildly varying results. > > On my Rock64('s) (RK3328) it doesn't work at all: > > ``` > root@cs21:~# cat /dev/hwrng | rngtest -c 1000 > rngtest 5 > ... > rngtest: starting FIPS tests... > cat: /dev/hwrng: No such device > rngtest: entropy source drained > ``` RK3399 and RK3328 are covered by a different driver: https://lore.kernel.org/all/20230707115242.3411259-1-clabbe@baylibre.com/ And that patch says the TRNG on the RK3328 is utterly broken. ChenYu > Cheers, > Diederik
On Wednesday, 17 July 2024 10:38:40 CEST Chen-Yu Tsai wrote: > > On my Rock64('s) (RK3328) it doesn't work at all: > > > > ``` > > root@cs21:~# cat /dev/hwrng | rngtest -c 1000 > > rngtest 5 > > ... > > rngtest: starting FIPS tests... > > cat: /dev/hwrng: No such device > > rngtest: entropy source drained > > ``` > > RK3399 and RK3328 are covered by a different driver: > > https://lore.kernel.org/all/20230707115242.3411259-1-clabbe@baylibre.com/ > > And that patch says the TRNG on the RK3328 is utterly broken. Yeah, someone made me aware of that post and then ofc I had to see it for myself ;-) Cheers, Diederik
On Wed, Jul 17, 2024 at 10:22:18AM +0200, Diederik de Haas wrote: > On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote: > > On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> 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/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6 > > > > rB2S7jg+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. > > > > > > Just for completeness, here my test result on the NanoPi R5C: > > > root@OpenWrt:~# 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 > > > > I doubt this is per-board. The RNG is inside the SoC, so it could be a chip > > quality thing. > > I agree with ChenYu (and others) that this is isn't a per-board level thing. > I'd even go further: 's/I doubt/It can't be that/' (for the same reason > though; this is inside the SoC). There are quite a lot of options regarding the implementation of an in-SoC RNG. Many of them rely on external components, such as a resistor or simply a pin left floating. Others may be influenced by the power delivery setup. Or rely on "thermal noise generated from inherently random quantum mechanical properties of silicon" (Intel). I don't know which design Rockchip chose, but just because the RNG is inside the SoC I wouldn't exclude the option that the quality it delivers may depend also on external components on the board, or even the dielectric properties of the board material itself, or (in case of bad designs) environmental circumstances such as the amount of electromagnetic noise around, and that then again depends on relative humidity, exposure to sunlight, ... The latter would be really bad, of course, because then we would have some kind of hidden sensor rather than a RNG, but nothing is too stupid to not show up when engineers of proprietary technologies are left alone. So imho only empirical data can tell. > > Before I saw these latest emails, I was going to suggest: > 1. Enable it only on RK3568 for now. I would be fine if this would be accepted > by the maintainer > > 2. Ask that you make a special version (for me) where I could play with the > params without having to compile a new kernel for each variant (it generally > takes me more then 24h on my Q64-A). Either through kernel module properties > or properties defined in the DeviceTree is fine with me. +1 Will do. > > 3. Based on the results make a choice to not enable it on rk3566 at all or > (indeed) introduce DT properties to configure it differently per SoC. > > 4. Hope/Ask for more test results > > > On the RK3399 we also saw wildly varying results. > > On my Rock64('s) (RK3328) it doesn't work at all: > > ``` > root@cs21:~# cat /dev/hwrng | rngtest -c 1000 > rngtest 5 > ... > rngtest: starting FIPS tests... > cat: /dev/hwrng: No such device > rngtest: entropy source drained > ``` > > Cheers, > Diederik
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 > > > > 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: 730 > > > > rngtest: FIPS 140-2 failures: 270 > > > > rngtest: FIPS 140-2(2001-10-10) Monobit: 266 > > > > rngtest: FIPS 140-2(2001-10-10) Poker: 23 > > > > rngtest: FIPS 140-2(2001-10-10) Runs: 9 > > > > 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=2.615; avg=137.889; > > > > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643; > > > > avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336 > > > > microseconds > > > > =========================================================== > > > > > > > > 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 > > > rngtest: FIPS 140-2(2001-10-10) Monobit: 293 > > > rngtest: FIPS 140-2(2001-10-10) Poker: 32 > > > rngtest: FIPS 140-2(2001-10-10) Runs: 10 > > > 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=2.612; avg=137.833; > > > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.391; > > > avg=34.416; max=68.364)Mibits/s rngtest: Program run time: 149736205 > > > microseconds > > > =========================================================== > > > > > > So that 704/296 vs 730/270 in the previous run on the PT2. > > > > > > In case it helps: > > > =========================================================== > > > root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_* > > > /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng > > > /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng > > > /sys/devices/virtual/misc/hw_random/rng_quality:900 > > > /sys/devices/virtual/misc/hw_random/rng_selected:0 > > > > > > root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_* > > > /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng > > > /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng > > > /sys/devices/virtual/misc/hw_random/rng_quality:900 > > > /sys/devices/virtual/misc/hw_random/rng_selected:0 > > > =========================================================== > > > > On my Rock 3A: > > > > wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000 > > rngtest 5 > > 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: 992 > > rngtest: FIPS 140-2 failures: 8 > > rngtest: FIPS 140-2(2001-10-10) Monobit: 7 > > rngtest: FIPS 140-2(2001-10-10) Poker: 0 > > rngtest: FIPS 140-2(2001-10-10) Runs: 0 > > rngtest: FIPS 140-2(2001-10-10) Long run: 1 > > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 > > rngtest: input channel speed: (min=2.658; avg=140.067; > > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=26.751; > > avg=34.901; max=65.320)Mibits/s rngtest: Program run time: 147367594 > > microseconds > > > > 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 > rngtest: FIPS 140-2(2001-10-10) Monobit: 879 > rngtest: FIPS 140-2(2001-10-10) Poker: 332 > rngtest: FIPS 140-2(2001-10-10) Runs: 91 > 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=2.615; avg=138.117; max=9765625.000)Kibits/s > rngtest: FIPS tests speed: (min=20.777; avg=34.535; max=68.857)Mibits/s > rngtest: Program run time: 149461754 microseconds > > 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 > rngtest: FIPS 140-2(2001-10-10) Monobit: 892 > rngtest: FIPS 140-2(2001-10-10) Poker: 335 > rngtest: FIPS 140-2(2001-10-10) Runs: 79 > 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=2.613; avg=138.098; max=9765625.000)Kibits/s > rngtest: FIPS tests speed: (min=20.465; avg=34.587; max=69.107)Mibits/s > rngtest: Program run time: 149475187 microseconds > > 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 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: 859 rngtest: FIPS 140-2 failures: 141 rngtest: FIPS 140-2(2001-10-10) Monobit: 137 rngtest: FIPS 140-2(2001-10-10) Poker: 10 rngtest: FIPS 140-2(2001-10-10) Runs: 5 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=134.990; avg=143.460; max=157.836)Kibits/s rngtest: FIPS tests speed: (min=34.742; avg=40.675; max=41.285)Mibits/s rngtest: Program run time: 136667679 microseconds root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000 rngtest 5 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: 843 rngtest: FIPS 140-2 failures: 157 rngtest: FIPS 140-2(2001-10-10) Monobit: 155 rngtest: FIPS 140-2(2001-10-10) Poker: 13 rngtest: FIPS 140-2(2001-10-10) Runs: 7 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=134.977; avg=143.669; max=157.906)Kibits/s rngtest: FIPS tests speed: (min=37.036; avg=40.666; max=41.285)Mibits/s rngtest: Program run time: 136459178 microseconds
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 for your tests, Diederik
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. :/
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?
On Tuesday, 30 July 2024 01:18:37 CEST 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. :/ FTR: I agree with Dragan, unfortunately. > 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? Unless we get *evidence* to the contrary, we should assume that the HWRNG on RK3568 is fine as the currently available test results are fine. So I think enabling it only for RK3568 is the right thing to do. So a 'revert' to v7 variant seems appropriate, but with the following changes: - Add `status = "disabled";` property to the definition in rk356x.dtsi - Add a new commit where you enable it only for rk3568 and document in the commit message why it's not enabled on rk3566 with a possible link to the v7 thread for clarification on why that is You could probably also integrate that into 1 commit, but make sure that the commit summary and description match the implementation. IMO that wasn't 'technically' the case in v8 as the rng node was added to rk356x, but it was only enabled on rk3568. My 0.02
Am Dienstag, 30. Juli 2024, 11:03:06 CEST schrieb Diederik de Haas: > On Tuesday, 30 July 2024 01:18:37 CEST 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. :/ > > FTR: I agree with Dragan, unfortunately. > > > 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? > > Unless we get *evidence* to the contrary, we should assume that the HWRNG on > RK3568 is fine as the currently available test results are fine. > So I think enabling it only for RK3568 is the right thing to do. > > So a 'revert' to v7 variant seems appropriate, but with the following changes: > - Add `status = "disabled";` property to the definition in rk356x.dtsi > - Add a new commit where you enable it only for rk3568 and document in the > commit message why it's not enabled on rk3566 with a possible link to the v7 > thread for clarification on why that is I was going to protest about the "disable" until reading the 2nd part :-D . And yeah that makes a lot of sense, "add" it to rk356x.dtsi, as the IP is part of both variants, but only enable it in rk3568.dtsi because of the seemingly faulty implementation on the rk3566. > You could probably also integrate that into 1 commit, but make sure that the > commit summary and description match the implementation. > IMO that wasn't 'technically' the case in v8 as the rng node was added to > rk356x, but it was only enabled on rk3568. > > My 0.02
On Tue, Jul 30, 2024 at 6:37 PM Heiko Stübner <heiko@sntech.de> wrote: > > Am Dienstag, 30. Juli 2024, 11:03:06 CEST schrieb Diederik de Haas: > > On Tuesday, 30 July 2024 01:18:37 CEST 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. :/ > > > > FTR: I agree with Dragan, unfortunately. > > > > > 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? > > > > Unless we get *evidence* to the contrary, we should assume that the HWRNG on > > RK3568 is fine as the currently available test results are fine. > > So I think enabling it only for RK3568 is the right thing to do. > > > > So a 'revert' to v7 variant seems appropriate, but with the following changes: > > - Add `status = "disabled";` property to the definition in rk356x.dtsi > > - Add a new commit where you enable it only for rk3568 and document in the > > commit message why it's not enabled on rk3566 with a possible link to the v7 > > thread for clarification on why that is > > I was going to protest about the "disable" until reading the 2nd part :-D . > > And yeah that makes a lot of sense, "add" it to rk356x.dtsi, as the IP is > part of both variants, but only enable it in rk3568.dtsi because of the > seemingly faulty implementation on the rk3566. Better yet, mark it as "broken" in rk3566.dtsi to reflect the tests that we've all done. ChenYu > > You could probably also integrate that into 1 commit, but make sure that the > > commit summary and description match the implementation. > > IMO that wasn't 'technically' the case in v8 as the rng node was added to > > rk356x, but it was only enabled on rk3568. > > > > My 0.02 > > > >
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.
Rockchip SoCs used to have a random number generator as part of their crypto device. However newer Rockchip SoCs like the RK3568 have an independent True Random Number Generator device. This patchset adds a driver for it and enables it in the device tree. Tested on FriendlyARM NanoPi R5C. v6 -> v7: * Patch 1: unchanged * Patch 2: bring back rk_rng_write_ctl() - bring back rk_rng_write_ctl() with improved comment to describe the hardware. * Patch 3: unchaned v5 -> v6: * Patch 1: unchanged * Patch 2: get rid of #ifdef - use if (IS_ENABLED(...)) { ... }instead of #ifdef inside functions - use __maybe_unused for functions previously enclosed by #ifdef'ery * Patch 3: unchanged v4 -> v5: * Patch 1: always use RK3568 name - use full RK3568 name in patch description - add RK3568 to title in binding * Patch 2: full name and cosmetics - also always mention RK3568 as there may be other RNG in other (future) Rockchip SoCs - remove debug output on successful probe - use MODULE_AUTHOR several times instead of single comma-separated * Patch 3: unchanged v3 -> v4: * Patch 1: minor corrections - fix Rokchip -> Rockchip typo - change commit title as requested * Patch 2: improved error handling and resource management - Always use writel() instead of writel_relaxed() - Use pm_runtime_resume_and_get - Correctly return error code in rk_rng_read() - Make use of devm_reset_control_array_get_exclusive - Use devm_pm_runtime_enable and there by get rid of rk_rng_remove() * Patch 3: - Move node to conform with ordering by address v2 -> v3: patch adopted by Daniel Golle * Patch 1: address comments of Krzysztof Kozlowski, add MAINTAINERS - improved description - meaningful clock-names - add entry in MAINTAINERS files * Patch 2: numerous code-style improvements - drop misleading rk_rng_write_ctl(), simplify I/O writes - drop unused TRNG_RNG_DOUT_[1-7] macros - handle error handling for pm_runtime_get_sync() - use memcpy_fromio() instead of open coding for-loop - some minor white-spaces fixes * Patch 3: - use clock-names as defined in dt-bindings v1 -> v2: * Patch 1: fix issues reported by Rob Herring and Krzysztof Kozlowski: - Rename rockchip-rng.yaml into rockchip,rk3568-rng.yaml - Fix binding title and description - Fix compatible property - Rename clocks and add the corresponding descriptions - Drop reset-names - Add a bus definition with #address-cells and #size-cells to the example. * Patch 2: fix issue reported by kernel test robot <lkp@intel.com> - Do not read the random registers as big endian, looking at the RK3568 TRM this is actually not needed. This fixes a sparse warning. * Patch 3: unchanged Aurelien Jarno (3): dt-bindings: rng: Add Rockchip RK3568 TRNG hwrng: add hwrng driver for Rockchip RK3568 SoC arm64: dts: rockchip: add DT entry for RNG to RK356x .../bindings/rng/rockchip,rk3568-rng.yaml | 61 +++++ MAINTAINERS | 7 + arch/arm64/boot/dts/rockchip/rk356x.dtsi | 9 + drivers/char/hw_random/Kconfig | 14 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/rockchip-rng.c | 227 ++++++++++++++++++ 6 files changed, 319 insertions(+) create mode 100644 Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml create mode 100644 drivers/char/hw_random/rockchip-rng.c