Low Entropy - 22.03-Snapshot (change in kernel entropy pool logic)

I just did a auc to the latest version of 22.03-Snapshot and I was poking around, I see I have low entropy today vs just last week. it's 256, where as last week, I could have sworn it was around 2-3k.

The last few things I did recently was to upgrade to latest version and installed libopenssl-devcrypto, iptables-nft, and luci-app-sqm.

How do I increase entropy on this device?

# cat /proc/sys/kernel/random/entropy_avail
256

# ps  |grep rng
  590 root         0 SW   [hwrng]
 4134 root       984 S    /sbin/urngd
 4330 root      1248 R    grep rng

# iwinfo wlan1-1 info
wlan1-1   ESSID: "Nuclear Missile Silo"
          Access Point: xxxx
          Mode: Master  Channel: 149 (5.745 GHz)
          Center Channel 1: 155 2: unknown
          Tx-Power: 27 dBm  Link Quality: 53/70
          Signal: -57 dBm  Noise: unknown
          Bit Rate: 725.9 MBit/s
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11nacax
          Hardware: 14C3:7915 14C3:7915 [MediaTek MT7915E]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

Firmware: OpenWrt 22.03-SNAPSHOT r19424-3b90edaff9
Kernel: 5.10.120
Hardware: RT3200

  • Enable on WiFi
  • Install rngd
1 Like

Attached is an strace output.

# strace /sbin/urngd
execve("/sbin/urngd", ["/sbin/urngd"], 0x7fce1553c0 /* 14 vars */) = 0
set_tid_address(0x7fa150b248)           = 5689
brk(NULL)                               = 0x11457000
brk(0x11459000)                         = 0x11459000
mmap(0x11457000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x11457000
openat(AT_FDCWD, "/etc/ld-musl-aarch64.path", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/libubox.so.20220515", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=53329, ...}) = 0
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0 3\0\0\0\0\0\0"..., 960) = 960
mmap(NULL, 122880, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7fa1456000
mmap(0x7fa1472000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xc000) = 0x7fa1472000
close(3)                                = 0
openat(AT_FDCWD, "/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=73744, ...}) = 0
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\267\0\1\0\0\0\0-\0\0\0\0\0\0"..., 960) = 960
mmap(NULL, 143360, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x7fa1433000
mmap(0x7fa1454000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x11000) = 0x7fa1454000
close(3)                                = 0
mprotect(0x7fa1472000, 4096, PROT_READ) = 0
mprotect(0x7fa1454000, 4096, PROT_READ) = 0
mprotect(0x412000, 4096, PROT_READ)     = 0
epoll_create1(0)                        = 3
fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
pipe2([4, 5], 0)                        = 0
fcntl(4, F_GETFD)                       = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
fcntl(4, F_GETFL)                       = 0 (flags O_RDONLY)
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
fcntl(5, F_GETFD)                       = 0
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
fcntl(5, F_GETFL)                       = 0x1 (flags O_WRONLY)
fcntl(5, F_SETFL, O_WRONLY|O_NONBLOCK|O_LARGEFILE) = 0
fcntl(4, F_GETFL)                       = 0x800 (flags O_RDONLY|O_NONBLOCK)
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 4, {events=EPOLLIN|EPOLLRDHUP, data={u32=2705797176, u64=548166643768}}) = 0
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_1 RT_2], NULL, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x7fa145b34c, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fa14c7808}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=0x7fa145b34c, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fa14c7808}, NULL, 8) = 0
rt_sigaction(SIGCHLD, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGCHLD, {sa_handler=0x7fa145b33c, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fa14c7808}, NULL, 8) = 0
rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fa14c7808}, NULL, 8) = 0
openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa1502000
openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/random", O_WRONLY|O_LARGEFILE) = 6
fcntl(6, F_GETFL)                       = 0x20001 (flags O_WRONLY|O_LARGEFILE)
fcntl(6, F_SETFL, O_WRONLY|O_NONBLOCK|O_LARGEFILE) = 0
epoll_ctl(3, EPOLL_CTL_ADD, 6, {events=EPOLLOUT, data={u32=4272200, u64=4272200}}) = 0
openat(AT_FDCWD, "/dev/kmsg", O_RDWR|O_LARGEFILE) = 7
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa1501000
ioctl(7, TIOCGWINSZ, 0x7fc4f63418)      = -1 ENOTTY (Not a tty)
writev(7, [{iov_base="<6>urngd: v1.0.2 started.\n", iov_len=26}, {iov_base=NULL, iov_len=0}], 2) = 26
close(7)                                = 0
munmap(0x7fa1501000, 4096)              = 0
ioctl(6, RNDADDENTROPY, {entropy_count=256, buf_size=64, buf="nO#\363S\4\376\347\374GV\326\374\263\273\277>x\270F\344\207\r\335&\300m\250\304\223b\314"...}) = 0
epoll_pwait(3,

WiFi traffic will increase entropy with most WiFi drivers. So, just having the router operating will likely gradually increase entropy. (Some drivers like mwlwifi are bad.)

"haveged" is a good package for maintaining the entropy level. Based on the havege algorithm. See https://www.issihosts.com/haveged/ for explanations
(I use it with my RT3200.)

3 Likes

@hnyman I installed haveged and started the daemon. How long do I need to wait for the entropy to go up? I still see it at 256 after 30mins or so.

# ps | egrep "hav|rng"
  590 root         0 SW   [hwrng]
 1098 root       984 S    /sbin/urngd
 1139 root      1760 S    /usr/sbin/haveged -F -w 1024 -d 32 -i 32 -v 1

# sysctl kernel.random.entropy_avail
kernel.random.entropy_avail = 256

That steady 256 sounds erroneous and suspicious as it is exactly 2^8 both times. There should be variation.

Haveged starts quickly and generates entropy quickly.

Dr Google says it's a change introduced in Linux kernel 5.10.119??

https://linkingin.co/top-trends-unix.stackexchange.com/questions/704737/kernel-5-10-119-caused-the-values-of-proc-sys-kernel-random-entropy-avail-and-p

Interesting.
The change in Linux seems to be part of a long patch series from the author of wireguard, and changes the random generation / entropy functions quite a bit.

Original commit in Feb 2022

Just to add some reference, I was running r19160-7ea2f3d6e2 (master) until saturday, before sysupgrading to (several-) newer snapshots since.

4 Likes

Might this explain why dropbear logins and SSH in general were extremely slow on a couple of the fairly recent 22.03 snapshots on my RT3200? Issue went away with later snapshots.

I haven't seen that (albeit with master/ v5.15.x on x86_64, c1037u and j1900), but with recent entropy reworks, /dev/random should no longer be blocking (because of insufficient entropy).

Is entropy reset every reboot?

This seemed to me a helpful explanation for those curious like me:

https://blog.cloudflare.com/ensuring-randomness-with-linuxs-random-number-generator/

Yes (it's complex, as a seed is retained/ restored).

3 Likes

Soo.. What does all this mean for OpenWRT users?

  1. Do I need to install haveged?
  2. Do I need to (dis|en)able urngd?
  3. Do I need to monitor entropy anymore with collectD? What am I looking for? What is good? What is bad?
  4. How do I know if there is a problem with entropy on my device X (RT3200)?

Sounds like the answers are:
Likely not needed any more.
Likely not needed.
No.
You don't.

1 Like

I found a few links about this subject.

The most important one AFAICT:
Random number generator enhancements for Linux 5.17 and 5.18 which I think explains the rational.

Possibly more random links :stuck_out_tongue_winking_eye:
https://lore.kernel.org/all/20220317232804.931702-1-Jason@zx2c4.com/ is a BIG pull request for Linus
https://lore.kernel.org/all/20211221175047.341782-1-Jason@zx2c4.com/
https://lore.kernel.org/all/20220201161342.154666-1-Jason@zx2c4.com/

I lack the knowledge to explain any part/rational/etc, but this should provide some references to those who could.

FTR: It seems it has been applied to the 5.10 series as well between 5.10.118 and 5.10.119. In fact it seems to be ~ the 'only' change that has been applied.

1 Like