[Buildroot] [PATCH] package/rng-tools: make jitterentropy conditional

[Matthew Weber]

Thomas,


On Mon, May 18, 2020 at 2:49 AM Thomas Petazzoni
<thomas.petazzoni at bootlin.com> wrote:
>
> Hello Matt,
>
> On Thu, 13 Feb 2020 11:07:36 -0600
> Matthew Weber <matthew.weber at rockwellcollins.com> wrote:
>
> > > We had similar issue today with am335x (kernel 5.4.x). Bumping
> > > rng-tools to v6.9 helped.
> >
> > Thank you for that feedback, I'll make this patch is superseded as the
> > bump resolved the bug.  I'll add a note with this patchwork thread in
> > the bug report as well.
>
> As I was going through open bug reports, I looked again at
> https://bugs.busybox.net/show_bug.cgi?id=12511, and I disagree with the
> conclusion of discarding this patch "package/rng-tools: make
> jitterentropy conditional".
>
> If I understand correctly:
>
>  - If you have a hardware RNG, the jitterentropy library is not
>    necessary.
>

Right,  jitterentropy  is a fall back if there isn't a hardware RNG
setup.  The performance impacts of having it enabled when there is a
hardware RNG were improved between versions and that was the
motivation to drop this patch as it didn't seem to still be a bug
(having it enabled when it isn't really needed).

>  - If you don't have a hardware RNG, rng-tools will error out, unless
>    jitterentropy support is enabled.

Correct.

>
> So, we really want to make the jitterentropy support in rng-tools
> optional, and leave it up to the user to enable it if (s)he has no
> hardware RNG available. And if there's no hardware RNG and no
> jitterentropy support, rng-tools will error out, the service will fail
> to start, and that's good. So the trick with the special 66 return code
> is not necessary.
>
> Do you agree ?

I agree, we should drop that rngd.service change but still keep the
option where a user could add the jitterentropy library if they need
it.

Regards,
Matt