Hi, On Fri, Mar 15, 2019 at 1:29 PM Petr Štetiar <yn...@true.cz> wrote: > > While testing simple firmware image for x86/64 in QEMU I've discovered > some weird behavior today. This image contains simple package with > simple init script to bootstrap the device UCI configuration from > network server. This init script uses uclient-fetch and libustream-openssl. > > This image was booting fine until today, usually finished booting under > 10s, but today it was booting much slowly, boot times were in range from > 60s to a few minutes. I was also unable to power off the QEMU with > poweroff command. > > I've found out, that it's all happening because of uclient-fetch being > blocked in getrandom syscall, leading for example to following: > > root@OpenWrt:~# time uclient-fetch > ^CCommand terminated by signal 2 > real 8m 31.08s > > The problem passes away after `random: crng init done` hits > the system log, but this step can take ages in some cases (usually when there > are more processes calling getrandom in parallel), but I couldn't get it > under 60s on my QEMU machine. I've similar weird reports from users on > MIPS devices as well. > > [ 13.786576] random: fast init done > ... > [ 653.153740] random: crng init done > > I've bisected the problem down to the following commit (reverting it > fixed the problem): > > # first bad commit: [d872d00b2f] openssl: update to version 1.1.1a > > So this patch tries to fix this issue by making getrandom syscall > nonblocking, and also removes possible usage of getentropy libc call, > which in case of musl libc results again in use of getrandom syscall in > blocking mode. > > I've also added new config option just in case someone would prefer to > have probably safer but much slower boot times on some devices.
I had a similar problem on some x86-devices. The problem is that OpenWRT-devices are so "quiet" that it takes a while before a sufficient amount of entropy is generated. Instead of disabling the blocking getrandom()-call, what I did to "solve" the issue was to install the haveged-packet on devices where I could not find a driver for the hardware generator. haveged attempts to provide an unpredictable random number generator, and I was able to get the crng init down to a couple of sections. haveged apparently has/had some issues with VMs (https://wiki.archlinux.org/index.php/Haveged), but most of them seems to have been resolved. BR, Kristian _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
