[OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Kristian Evensen]

Hi,

On Fri, Mar 15, 2019 at 1:29 PM Petr Štetiar <ynezz at 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 at 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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel