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

[Mark Hatle]

On 5/8/19 5:22 PM, 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.

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.)

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.

--Mark

> -Mikko
>