On Wed, May 08, 2019 at 06:50:54PM +0300, Mark Hatle wrote:
> On 5/8/19 5:22 PM, 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.
>
> I agree with Adrian here. It should be a recommend. The system works without
> this, and there are valid use-cases without rngd existing on the system. (In
> fact I have a couple of customers that would rather the system stall waiting
> for
> 'real' entropy then use the values from rngd.)
Ok, at least I tried.
I can send a v2 with RRECOMMENDS instead though it is useless for me
since enabling recommends causes images to explode in size, complexity,
licensing with GPLv3 components etc.
> Note the warning on this page: https://wiki.archlinux.org/index.php/Rng-tools
>
> In a lot of cases, this dependency on urandom on an embedded target without
> even
> a clock or entropy sources results in the system having effectively the same
> entropy each time it starts up -- even with rngd. So you get a false sense of
> security.
>
> Once you have a hardware (or other) rng source, the tool can be useful to
> increase the amount of entropy available however... but it all starts with
> having a reasonable starting source.
>
> In your case, if using rngd has the entropy your device requires, based on
> your
> system configuration (and you do not want recommends), then I think it's
> reasonable that you need to manually include it as an image dependency.
Yes, this lack of entropy on embedded devices is understood but in my case
rngd is the one reading /dev/hwrnd and pushing that back to kernel...
-Mikko
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
