Bug 12511

Summary:	rng-tools has forced dependency on jitterentropy-library ; It slows boot considerably
Product:	buildroot	Reporter:	Axel Voitier <axel.voitier>
Component:	Other	Assignee:	Matt Weber <matthew.weber>
Status:	RESOLVED MOVED
Severity:	normal	CC:	buildroot, yann.morin.1998
Priority:	P5
Version:	2019.11.1
Target Milestone:	---
Hardware:	All
OS:	Linux
Host:		Target:
Build:

Description Axel Voitier 2020-01-28 15:37:55 UTC

Hello,

Updating from 2019.05 to 2019.11.1, I noticed the boot time on my target (iMX6) increased by ~20s. Culprit was quickly found: rngd.

Apparently we went from rng-tools 5 to 6.7. A bit more digging led me to figure out that the actual culprit is the new jitterentropy source added relatively recently to rng-tools.

This library provide entropy source from CPU timings jitter it seems. That's probably very nice for system without hardware RNG. But even if you have one, the jitter source remains enabled by default and slows the start up of rngd significatively.

Now, the quick solution is to add 'DAEMON_ARGS+="-x jitter"' to /etc/default/rngd. But first, that might take some digging for affected users to figure this out.

Second, I don't think it is actually right that buildroot package for rng-tools force the dependency on jitterentropy-library, as it is not strictly necessary to compile and install it.
Sure, you want to provide a nice and easy default for users of targets without HWRNG. But that impacts negatively users who do have HWRNG.

I would suggest to either provide static options for that in menuconfig.
Or, I don't know if it is possible for a .mk package file to reference a kernel option, but it could be possible to detect if kernel has a driver enabled for either a /dev/hwrng provider, or a TPM device.
Could also be done from /etc/init.d/S21rngd?


Cheers,
Axel

Comment 1 Matt Weber 2020-01-28 18:31:01 UTC

Sorry to hear about the boot delay issue.  The reason it was added by default was I noticed the init script had handled a case of adding entropy when a hwrng wasn't present. I didn't realize the impact when hwrng was enabled.

I agree, I think something like a new kconfig sub option named "enable source jitterentropy" under rngd might be best (with a solid help description outlining when to enable it).  There isn't a ideal way to get a linux config option to trigger a dependency in the buildroot build.

We could tailor the initscript and have it check if there is a hwrng enabled by checking for dev node existence if that is consistance.  However we can't probably depend on the linux config being present and parse-able.

Comment 2 Matt Weber 2020-02-05 18:27:14 UTC

Would you mind testing this proposed fix?
http://patchwork.ozlabs.org/patch/1233971/

Comment 3 Axel Voitier 2020-02-06 13:36:04 UTC

(In reply to Matt Weber from comment #2)

I can confirm it works in my case.
Although, I am not using systemd, so I cannot test that part of the patch.


Cheers,
Axel

Comment 4 Matt Weber 2020-02-11 15:02:30 UTC

Looks like there is a updated rng-tools version.  Would you mind testing this patch without the proposed jitterentropy selection changes I previously proposed?

http://patchwork.ozlabs.org/patch/1235396/

Comment 5 Matt Weber 2020-02-13 17:10:46 UTC

Yegor noted in the http://patchwork.ozlabs.org/patch/1233971/ thread that the bump of rng-tools made the startup cost of having jitterentropy as a source better. 

Axel, I'll let you confirm if you feel this did enough or if we still need to breakout providing the user an option.

Comment 6 Scott Bartolett 2021-09-29 20:16:12 UTC

Has this issue been resolved.  I am using Buildroot-2021.08 and targeting the RPI Zero with no input device.  I need a minimal system for fast boot and so have removed BusyBox (set Init System to None) and using devtmpfs + mdev. I have tried all combinations of HW_RANDOM in the kernel and rng-tools, Jitternentropy Library and NIST Entropy Beacon support.  In all cases there is a very long delay before finally getting the random: crng init done message.

Comment 7 Yann E. MORIN 2024-06-15 14:52:23 UTC

Thank you for your report.

The issue tracker for the Buildroot project has been moved to
the Gitlab.com issue tracker:
    https://gitlab.com/buildroot.org/buildroot/-/issues

We are taking this opportunity to close old issues in this old
tracker. If you believe your issue is still relevant, please
open one in the new issue tracker.

Thank you!