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.

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

FS#1979 - syscall getrandom() hangs on Turris Omnia #8448

Closed
openwrt-bot opened this issue Nov 30, 2018 · 3 comments
Closed

FS#1979 - syscall getrandom() hangs on Turris Omnia #8448

openwrt-bot opened this issue Nov 30, 2018 · 3 comments
Labels

Comments

@openwrt-bot
Copy link

smutt:

Supply the following if possible:

  • Device problem occurs on
  • Software versions of OpenWrt/LEDE release, packages, etc.
  • Steps to reproduce

root@OpenWrt:/~# uname -a
Linux OpenWrt 4.14.63 #0 SMP Wed Aug 15 20:42:39 2018 armv7l GNU/Linux

root@OpenWrt:~# cat /proc/version
Linux version 4.14.63 (buildbot@builds-03.infra.lede-project.org) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r7101-a63e38b)) #0 SMP Wed Aug 15 20:42:39 2018

root@OpenWrt:~# uptime
14:40:46 up 1:14, load average: 0.00, 0.00, 0.00

root@OpenWrt:# cat /proc/device-tree/model
Turris Omniaroot@OpenWrt:
#

root@OpenWrt:~# ps |grep rand
2228 root 1128 S /bin/sh /sbin/urandom_seed
2247 root 748 S getrandom 512
3114 root 1056 R grep rand

root@OpenWrt:~# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 1600.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1

processor : 1
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 1600.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x4
CPU part : 0xc09
CPU revision : 1

Hardware : Marvell Armada 380/385 (Device Tree)
Revision : 0000
Serial : 0000000000000000

root@OpenWrt:~# cat /proc/devices
Character devices:
1 mem
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
10 misc
89 i2c
90 mtd
108 ppp
128 ptm
136 pts
180 usb
189 usb_device
251 watchdog
252 rtc
253 ttyMV
254 gpiochip

Block devices:
7 loop
8 sd
31 mtdblock
65 sd
66 sd
67 sd
68 sd
69 sd
70 sd
71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
179 mmc
254 ubiblock
259 blkext

root@OpenWrt:~# ls -l /dev/|grep rand
crw-rw-rw- 1 root root 1, 8 Nov 30 13:26 random
crw-rw-rw- 1 root root 1, 9 Nov 30 13:26 urandom

I am using the stock images from here:
https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-initramfs-kernel.bin
https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-kernel.bin
https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-sysupgrade.img.gz

I discovered this when troubleshooting why unbound would not start. I could see with strace that unbound was getting stuck at the getrandom() syscall, and at first I thought it was a problem with unbound. But then I saw that /usr/bin/getrandom 512 had been stuck since boot. The syscall just blocks forever.

root@OpenWrt:# which getrandom
/usr/bin/getrandom
root@OpenWrt:
# strace /usr/bin/getrandom 512 >/tmp/derp.txt
execve("/usr/bin/getrandom", ["/usr/bin/getrandom", "512"], 0xbead7df4 /* 13 vars */) = 0
set_tls(0xb6f31544, 0xbe8aec28, 0x490ceab4, 0, 0xb6f314a0) = 0
set_tid_address(0xb6f314bc) = 3132
open("/etc/ld-musl-armhf.path", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/libgcc_s.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=41251, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\20<\0\0004\0\0\0"..., 936) = 936
mmap2(NULL, 110592, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb6ea0000
mmap2(0xb6eb9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x9000) = 0xb6eb9000
close(3) = 0
mprotect(0xb6eb9000, 4096, PROT_READ) = 0
mprotect(0x20000, 4096, PROT_READ) = 0
ioctl(1, TIOCGWINSZ, 0xbe8aec80) = -1 ENOTTY (Not a tty)
getrandom(

'/usr/bin/head /dev/urandom' returns random data like you expect.
'/usr/bin/head /dev/random' just hangs.

@openwrt-bot
Copy link
Author

dshcherb:

I can confirm this behavior.

root@OpenWrt:~# strace -f /usr/sbin/unbound -d -c /var/lib/unbound/unbound.conf # ... getpid() = 4330 getpid() = 4330 getrandom(

I believe this happens because the driver for the crypto chip used in Omnia (atsha204) was never upstreamed and, therefore, is not used.

https://gitlab.labs.nic.cz/turris/turris-omnia-uboot/blob/omnia/drivers/misc/atsha204-i2c.c

I can see in the kernel log that the urandom source has not been initialized:

root@OpenWrt:~# dmesg | grep rand [ 0.000000] random: get_random_bytes called from 0xc08008d0 with crng_init=0 [ 3.623942] random: jshn: uninitialized urandom read (4 bytes read) [ 3.657935] random: jshn: uninitialized urandom read (4 bytes read) [ 3.672295] random: jshn: uninitialized urandom read (4 bytes read) [ 6.766563] urandom_read: 2 callbacks suppressed [ 6.766566] random: procd: uninitialized urandom read (4 bytes read) [ 7.125280] random: fast init done [ 7.176981] urandom-seed: Seed file not found (/etc/urandom.seed) [ 7.882315] random: ubusd: uninitialized urandom read (4 bytes read) [ 7.917686] random: ubusd: uninitialized urandom read (4 bytes read) [ 7.924152] random: ubusd: uninitialized urandom read (4 bytes read)

Based on //getrandom// syscall manpage this means that any call made without an explicit non-blocking flag will stay blocked until urandom source is initialized.

http://man7.org/linux/man-pages/man2/getrandom.2.html
"If the urandom source has not yet been initialized, then getrandom() will block, unless GRND_NONBLOCK is specified in flags."

CONFIG_ATH9K_HWRNG (https://elixir.bootlin.com/linux/v4.14.91/source/drivers/net/wireless/ath/ath9k/Kconfig#L185) is not enabled for any targets yet:

https://github.com/openwrt/openwrt/blob/openwrt-18.06/target/linux/generic/config-4.14
https://github.com/openwrt/openwrt/blob/openwrt-18.06/target/linux/mvebu/config-4.14

So, even if wireless modules are enabled, radio noise is not used as a source for the kernel entropy pool.

I was able to get around that by using haveged:

# before haveged - not enough entropy, getrandom(2) blocks cat /proc/sys/kernel/random/entropy_avail 18

root@OpenWrt:~# opkg install haveged
Installing haveged (1.9.4-1) to root...
Downloading http://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9_vfpv3/packages/haveged_1.9.4-1_arm_cortex-a9_vfpv3.ipk
Installing libhavege (1.9.4-1) to root...
Downloading http://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9_vfpv3/packages/libhavege_1.9.4-1_arm_cortex-a9_vfpv3.ipk
Configuring libhavege.
Configuring haveged.
haveged: listening socket at 5

haveged generates enough entropy and getrandom(2) unblocks (unbound unblocks as well)

root@OpenWrt:~# cat /proc/sys/kernel/random/entropy_avail
2236

Haveged seems to be using clock_gettime(CLOCK_MONOTONIC) on this platform which hopefully gives a good enough result with armada38x-rtc

https://github.com/jirka-h/haveged/blob/1.9.4/README#L149-L154

root@OpenWrt:~# dmesg | grep rtc [ 1.425711] armada38x-rtc f10a3800.rtc: rtc core: registered f10a3800.rtc as rtc0 [ 2.983481] armada38x-rtc f10a3800.rtc: setting system clock to 2019-01-03 00:17:14 UTC (1546474634)

https://github.com/openwrt/openwrt/blob/master/target/linux/generic/config-4.14#L1672
CONFIG_HIGH_RES_TIMERS=y

@openwrt-bot
Copy link
Author

smutt:

Thank you!

I installed haveged and this worked around the issue. It's still an issue and it would be good if cz.nic could upstream the driver for their atsha204. It would be better to have hardware entropy and not have to rely on software. But good to have a workaround.

--Andrew

@openwrt-bot
Copy link
Author

dshcherb:

Andrew,

I agree with that for sure. I raised a forum topic to discuss that: https://forum.turris.cz/t/question-atsha204-driver-upstreaming/9104

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant