<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 10, 2019 at 8:18 AM Burton, Ross <<a href="mailto:ross.burton@intel.com">ross.burton@intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm very dubious of the need to make this a dependency, as the<br>
hardware RNG should be used. Note that there's been a slew of fixes<br>
to the kernel to enable this with modern stacks, for example:<br>
<br>
<a href="https://github.com/torvalds/linux/commit/62f95ae805fa9e1e84d47d3219adddd97b2654b7" rel="noreferrer" target="_blank">https://github.com/torvalds/linux/commit/62f95ae805fa9e1e84d47d3219adddd97b2654b7</a><br>
<br>
Maybe the IMX driver needs the same patch?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">In my experience, not all boards have a usable hw RNG that can solve the problem.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">That being said, I have no strong opinion on it being a RRECOMMENDS, or not mentioned</div><div class="gmail_default" style="font-size:small">at all. Since a BSP really is the place that knows if a usable hwrng is available, and some sort</div><div class="gmail_default" style="font-size:small">of machine feature or distro layer could pull in the dependency for boards that know they</div><div class="gmail_default" style="font-size:small">need the daemons.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Bruce</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Ross<br>
<br>
On Thu, 9 May 2019 at 09:46, Rasmus Villemoes<br>
<<a href="mailto:rasmus.villemoes@prevas.dk" target="_blank">rasmus.villemoes@prevas.dk</a>> wrote:<br>
><br>
> On 08/05/2019 16.22, <a href="mailto:Mikko.Rapeli@bmw.de" target="_blank">Mikko.Rapeli@bmw.de</a> wrote:<br>
> > On Wed, May 08, 2019 at 05:07:08PM +0300, Adrian Bunk wrote:<br>
> >> On Wed, May 08, 2019 at 04:26:09PM +0300, Mikko Rapeli wrote:<br>
> >>> Since openssl 1.1.1 and openssh which uses it, sshd<br>
> >>> startup is delayed. The delays range from few seconds<br>
> >>> to minutes and even to hours. The delays are visible<br>
> >>> in host keys generation and when sshd process is started<br>
> >>> in response to incoming TCP connection but is failing<br>
> >>> to provide SSH version string and clients or tests time out.<br>
> >>><br>
> >>> In all cases traces show that sshd is waiting for getentropy()<br>
> >>> system call to return from Linux kernel, which returns only<br>
> >>> after kernel side random number pool is initialized. The pool<br>
> >>> is initialized via various entropy source which may be<br>
> >>> missing on embedded development boards or via rngd from<br>
> >>> rng-tools package from userspace. HW random number generation<br>
> >>> and kernel support help but rngd is till needed to feed that data<br>
> >>> back to the Linux kernel.<br>
> >>><br>
> >>> Example from an NXP imx8 board shows that kernel random number pool<br>
> >>> initialization can take over 400 seconds without rngd,<br>
> >>> and with rngd it is initialized at around 4 seconds after boot.<br>
> >>> The completion of initialization is visible in kernel dmesg with line<br>
> >>> "random: crng init done".<br>
> >>> ...<br>
> >>> --- a/meta/recipes-connectivity/openssh/<a href="http://openssh_7.9p1.bb" rel="noreferrer" target="_blank">openssh_7.9p1.bb</a><br>
> >>> +++ b/meta/recipes-connectivity/openssh/<a href="http://openssh_7.9p1.bb" rel="noreferrer" target="_blank">openssh_7.9p1.bb</a><br>
> >>> @@ -148,6 +148,7 @@ FILES_${PN}-keygen = "${bindir}/ssh-keygen"<br>
> >>><br>
> >>> RDEPENDS_${PN} += "${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen"<br>
> >>> RDEPENDS_${PN}-sshd += "${PN}-keygen ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam-plugin-keyinit pam-plugin-loginuid', '', d)}"<br>
> >>> +RDEPENDS_${PN}-sshd += "rng-tools"<br>
> >>> ...<br>
> >><br>
> >> This should only be an RRECOMMENDS so that people can opt out of it.<br>
> >><br>
> >> E.g. CONFIG_RANDOM_TRUST_CPU in the kernel can solve the same<br>
> >> problem without using rng-tools on some platforms.<br>
> ><br>
> > I think this is a stronger dependency than just RRECOMMENDS. We build<br>
> > images and disable recommends but we care that sshd starts as fast as in<br>
> > sumo and earlier yocto releases for testing etc purposes.<br>
><br>
> But why should boards without a hwrng be forced to spend disk space and<br>
> run-time resources on a daemon which they don't benefit from at all?<br>
><br>
> I don't think RANDOM_TRUST_CPU works, though. That's just for stuff like<br>
> rdrand(), i.e. instructions built into the CPU - not for some other<br>
> on-chip hwrng. Whether those are used for seeding early on (i.e.,<br>
> without rngd doing its thing) depends on the ->quality parameter set by<br>
> the individual hwrng drivers. Very few set one, so they get assigned the<br>
> default_quality, which is a module parameter that defaults to 0.<br>
><br>
> IOW, I think (but I haven't got around to testing this) one should set<br>
> rng_core.default_quality=512 (or something) on the kernel command line<br>
> to make the kernel start the hwrng_fill thread that will seed the<br>
> entropy pool from the hwrng. At least if I'm reading<br>
> drivers/char/hw_random/core.c correctly.<br>
><br>
> Rasmus<br>
><br>
><br>
><br>
><br>
> --<br>
> _______________________________________________<br>
> Openembedded-core mailing list<br>
> <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end<br>- "Use the force Harry" - Gandalf, Star Trek II<br><br></div></div>