On 08/05/2019 16.22, mikko.rap...@bmw.de wrote: > On Wed, May 08, 2019 at 05:07:08PM +0300, Adrian Bunk wrote: >> On Wed, May 08, 2019 at 04:26:09PM +0300, Mikko Rapeli wrote: >>> Since openssl 1.1.1 and openssh which uses it, sshd >>> startup is delayed. The delays range from few seconds >>> to minutes and even to hours. The delays are visible >>> in host keys generation and when sshd process is started >>> in response to incoming TCP connection but is failing >>> to provide SSH version string and clients or tests time out. >>> >>> In all cases traces show that sshd is waiting for getentropy() >>> system call to return from Linux kernel, which returns only >>> after kernel side random number pool is initialized. The pool >>> is initialized via various entropy source which may be >>> missing on embedded development boards or via rngd from >>> rng-tools package from userspace. HW random number generation >>> and kernel support help but rngd is till needed to feed that data >>> back to the Linux kernel. >>> >>> Example from an NXP imx8 board shows that kernel random number pool >>> initialization can take over 400 seconds without rngd, >>> and with rngd it is initialized at around 4 seconds after boot. >>> The completion of initialization is visible in kernel dmesg with line >>> "random: crng init done". >>> ... >>> --- a/meta/recipes-connectivity/openssh/openssh_7.9p1.bb >>> +++ b/meta/recipes-connectivity/openssh/openssh_7.9p1.bb >>> @@ -148,6 +148,7 @@ FILES_${PN}-keygen = "${bindir}/ssh-keygen" >>> >>> RDEPENDS_${PN} += "${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen" >>> RDEPENDS_${PN}-sshd += "${PN}-keygen >>> ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam-plugin-keyinit >>> pam-plugin-loginuid', '', d)}" >>> +RDEPENDS_${PN}-sshd += "rng-tools" >>> ... >> >> This should only be an RRECOMMENDS so that people can opt out of it. >> >> E.g. CONFIG_RANDOM_TRUST_CPU in the kernel can solve the same >> problem without using rng-tools on some platforms. > > I think this is a stronger dependency than just RRECOMMENDS. We build > images and disable recommends but we care that sshd starts as fast as in > sumo and earlier yocto releases for testing etc purposes.
But why should boards without a hwrng be forced to spend disk space and run-time resources on a daemon which they don't benefit from at all? I don't think RANDOM_TRUST_CPU works, though. That's just for stuff like rdrand(), i.e. instructions built into the CPU - not for some other on-chip hwrng. Whether those are used for seeding early on (i.e., without rngd doing its thing) depends on the ->quality parameter set by the individual hwrng drivers. Very few set one, so they get assigned the default_quality, which is a module parameter that defaults to 0. IOW, I think (but I haven't got around to testing this) one should set rng_core.default_quality=512 (or something) on the kernel command line to make the kernel start the hwrng_fill thread that will seed the entropy pool from the hwrng. At least if I'm reading drivers/char/hw_random/core.c correctly. Rasmus -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core