[OE-core] [PATCH 2/2] openssh: usable sshd depends on rngd from rng-tools

[Burton, Ross]

I'm very dubious of the need to make this a dependency, as the
hardware RNG should be used.  Note that there's been a slew of fixes
to the kernel to enable this with modern stacks, for example:

https://github.com/torvalds/linux/commit/62f95ae805fa9e1e84d47d3219adddd97b2654b7

Maybe the IMX driver needs the same patch?

Ross

On Thu, 9 May 2019 at 09:46, Rasmus Villemoes
<rasmus.villemoes at prevas.dk> wrote:
>
> On 08/05/2019 16.22, Mikko.Rapeli at 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 at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core