Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RK3328 HWRNG output Low quality random numbers #223

Closed
wevsty opened this issue Aug 25, 2020 · 3 comments
Closed

RK3328 HWRNG output Low quality random numbers #223

wevsty opened this issue Aug 25, 2020 · 3 comments

Comments

@wevsty
Copy link

wevsty commented Aug 25, 2020

I was trying to use HWRNG with the RK3328, but when I tested /dev/hwrng I found that the output didn't pass the random number test.
This means that the quality of the output random numbers is very low and I'm not sure if this is a problem with the HWRNG code or a flaw in the chip itself.
The test results are as follows.

root@rockchip-linux:~# hexdump -n 128 /dev/hwrng
0000000 b978 e14c 78fc ec33 b501 35b3 6470 2724
0000010 2918 084d 2a07 461f 81d9 6f60 3899 ace4
0000020 b4c0 54c9 110e 5097 9be9 244a d7c8 e18e
0000030 665a 9e60 d80c f820 cf15 7ecc e660 8f67
0000040 99fc 44aa a6d2 0224 588a 00fe 4a8d 44d8
0000050 987f 6d4b 4921 021c 079c da28 44a0 ac64
0000060 1e5b d97c ccff 5092 5489 38ca 72b2 6ba1
0000070 3f66 1d08 2dc9 4b58 e161 cec4 5303 cb02
0000080

root@rockchip-linux:~# cat /dev/hwrng | rngtest -c 100000
rngtest 6.7
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: 2000000032
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 100000
rngtest: FIPS 140-2(2001-10-10) Monobit: 100000
rngtest: FIPS 140-2(2001-10-10) Poker: 100000
rngtest: FIPS 140-2(2001-10-10) Runs: 100000
rngtest: FIPS 140-2(2001-10-10) Long run: 313
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=404.541; avg=1073.877; max=4882812.500)Kibits/s
rngtest: FIPS tests speed: (min=4.523; avg=18.105; max=59.605)Mibits/s
rngtest: Program run time: 1924394866 microseconds

From the hexdump results, the driver is working properly, but the quality of the output is not high.

If it is a driver problem is there a way to fix it?
@wevsty
Copy link
Author

wevsty commented Aug 28, 2020

After an email exchange, the advice I got was
Adjust the value of CRYPTO_V1_TRNG_SAMPLE_PERIOD.

File path : kernel/drivers/char/hw_random/rockchip-rng.c
Expanding CRYPTO_V1_TRNG_SAMPLE_PERIOD can strengthen the quality of the random number.

@wevsty wevsty closed this as completed Aug 28, 2020
@tstevens tstevens mentioned this issue Apr 6, 2021
Closed
2 tasks
@tstevens
Copy link

tstevens commented Apr 6, 2021

@wevsty was there a value of CRYPTO_V1_TRNG_SAMPLE_PERIOD that worked for you?

@wevsty
Copy link
Author

wevsty commented Apr 7, 2021

@wevsty was there a value of CRYPTO_V1_TRNG_SAMPLE_PERIOD that worked for you?

I suggest you try adjusting it to above 1000.

Kwiboo pushed a commit to Kwiboo/linux-rockchip that referenced this issue Feb 7, 2023
@mpe
powerpc/kexec_file: Fix division by zero in extra size estimation
7294194 
In kexec_extra_fdt_size_ppc64() there's logic to estimate how much
extra space will be needed in the device tree for some memory related
properties.

That logic uses the size of RAM divided by drmem_lmb_size() to do the
estimation. However drmem_lmb_size() can be zero if the machine has no
hotpluggable memory configured, which is the case when booting with qemu
and no maxmem=x parameter is passed (the default).

The division by zero is reported by UBSAN, and can also lead to an
overflow and a warning from kvmalloc, and kdump kernel loading fails:

  WARNING: CPU: 0 PID: 133 at mm/util.c:596 kvmalloc_node+0x15c/0x160
  Modules linked in:
  CPU: 0 PID: 133 Comm: kexec Not tainted 6.2.0-rc5-03455-g07358bd97810 rockchip-linux#223
  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf000005 of:SLOF,git-dd0dca pSeries
  NIP:  c00000000041ff4c LR: c00000000041fe58 CTR: 0000000000000000
  REGS: c0000000096ef750 TRAP: 0700   Not tainted  (6.2.0-rc5-03455-g07358bd97810)
  MSR:  800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 24248242  XER: 2004011e
  CFAR: c00000000041fed0 IRQMASK: 0
  ...
  NIP kvmalloc_node+0x15c/0x160
  LR  kvmalloc_node+0x68/0x160
  Call Trace:
    kvmalloc_node+0x68/0x160 (unreliable)
    of_kexec_alloc_and_setup_fdt+0xb8/0x7d0
    elf64_load+0x25c/0x4a0
    kexec_image_load_default+0x58/0x80
    sys_kexec_file_load+0x5c0/0x920
    system_call_exception+0x128/0x330
    system_call_vectored_common+0x15c/0x2ec

To fix it, skip the calculation if drmem_lmb_size() is zero.

Fixes: 2377c92 ("powerpc/kexec_file: fix FDT size estimation for kdump kernel")
Cc: stable@vger.kernel.org # v5.12+
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20230130014707.541110-1-mpe@ellerman.id.au
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tstevens @wevsty