[Buildroot] [PATCH] package/rng-tools: make jitterentropy conditional
matthew.weber at rockwellcollins.com
Tue Feb 11 15:03:23 UTC 2020
On Sat, Feb 8, 2020 at 1:13 PM Peter Korsgaard <peter at korsgaard.com> wrote:
> >>>>> "Matthew" == Matthew Weber <matthew.weber at rockwellcollins.com> writes:
> > Thomas,
> > On Wed, Feb 5, 2020 at 2:46 PM Matthew Weber
> > <matthew.weber at rockwellcollins.com> wrote:
> >> Thomas,
> >> On Wed, Feb 5, 2020 at 1:33 PM Thomas Petazzoni
> >> <thomas.petazzoni at bootlin.com> wrote:
> >> >
> >> > On Wed, 5 Feb 2020 12:26:08 -0600
> >> > Matt Weber <matthew.weber at rockwellcollins.com> wrote:
> >> >
> >> > > The update of rng-tools from 5 to 6.7 introduced a change where
> >> > > the jitterentropy library was enabled by default instead of
> >> > > returning a special 66 return code to hangle the case of no
> >> > > hwrng. This patch reverts that change and allows a user to
> >> > > select when to enable the jitterentropy source. The bug
> >> > > documents an issue of when a hwrng is enabled with jitterentropy
> >> > > there is a longer boot time.
> >> >
> >> > I don't understand this story of the 66 return code. Could you explain
> >> > a bit more ?
> >> In Buildroot commit 22cb51e1 the systemd support addition included the
> >> successcode change based on the Fedora bugfix for ignoring if no hwrng
> >> is present (https://bugzilla.redhat.com/show_bug.cgi?id=892178).
> > Ryan Barnett noticed that rng-tools dropped the special return code.
> > I guess we could just drop support for this special case as well....
> > https://github.com/nhorman/rng-tools/blob/v6.8/rngd.c#L805
> Has that Fedora patch ever been included upstream? I don't seem to find
> it in the history.
It doesn't look like it. I'm wondering if we should just drop this
systemd unit return behavior and put a comment in the service file
about enabling an entropy package if this service fails without a
hardware rng present. Seems too complicated to try and cover this
> I btw see there is a 6.9 release with more bugfixes, care to send a
> patch bumping the version?
I'll review the one that was just sent. I also ping'd the original
bug report to see if they could test with this bump as there are a
number of minor jitterentropy related fixes.
More information about the buildroot