[Buildroot] [PATCH v2 1/2] package/haveged: Change service file to run early

[Alexander Dahl <post@lespocky.de>]

Hei hei,

On Tue, Jun 30, 2020 at 09:46:12AM +0200, Norbert Lange wrote:
> Am Mo., 29. Juni 2020 um 23:38 Uhr schrieb Alexander Dahl <post@lespocky.de>:
> > I just took some time and read the havege source.  It's not just
> > seeding with one timestamp or something, the jitter is the noise
> > source, and new jitter data is gathered by doing calculations, and
> > measuring timings (and doing some calculations on top) on each read to
> > the havege rng.
> 
> Point is its not entropy but a PRNG with (re)seeds, the only qualification
> seems to be that it passes tests. To quote a kernel dev [1]:
> "One of Peter's colleagues replaced the random input source employed
> by HAVEGE with a constant stream of ones. All of the same tests
> passed."
> 
> Means the PRNG is enough to pass the tests. There is no good argument that
> the entropy it gathers is of good quality.
> 
> > > Its not just entropy, you dont have any measure on how much entropy
> > > you get from jitter,
> > > especially on embedded systems or VMs where you would haveged in the
> > > first place.
> >
> > I'm no expert on RNG, not at all.  But how is an embedded system or a
> > virtual machine CPU different from other systems here, if the noise
> > source is the CPU itself only?
> 
> haveged depends on jitters in the kernel scheduler and cache/pipeline
> characteristics.
> Those aren't the source of noise (entropy in this context), those are
> consequences of other noises
> (skew between multiple clock sources, IRG/device/filesystem/net timings).
> On isolated systems you have less of that noise (and on embedded
> simpler, more predictable CPUs aswell).
> 
> The CPU is fully deterministic without those outside influences, even
> if no one is practically able to do so.
> (You might have heard of all the spectre issues where some smart
> people figured some details out anyway).
> 
> >
> > > > > I am not up to speed with FIPS tests, but from a really really long way back
> > > > > it wasn't a big issue to pass most tests with the Mersenne Twister and a few
> > > > > bits of true entropy.
> > > > >
> > > > > Basically it feeds PRNG back to kernel and lets it account as entropy source.
> > > >
> > > > I could not find any backup for that claim.  If I understood
> > > > correctly, haveged does not read from the kernel PRNG.
> > >
> > > The kernel has an entropy pool, it taps alot sources (inkl jitter, see
> > > https://lwn.net/Articles/642166/).
> >
> > Yes, but according to Stephan M?ller, the author of the
> > jitterentropy-rng, the kernel uses the CPU timing jitter internally
> > only in the crypto subsystem, that's not fed to the pool /dev/random
> > uses [1].  There's a patch series for a redesigned random number
> > subsystem by him, which would make that possible, but that never got
> > merged.
> 
> Maybe because no one trusts self-generated jitter as source for
> entropy for a reason (as a RNG its another matter)?
> You need entropy from outside the CPU (not counting embedded entropy
> hardware/instructions)
>  everything else can be assumed a deterministic feedback loop.
> 
> > > what haveged does is overaccounting the very little true entropy it
> > > fetches (by using a PRNG on top AFAIU).
> >
> > That may be, I did not read and understood the haveged source good
> > enough to prove or disprove that.
> 
> See quote above, even if the entropy is removed, it will feed the
> kernel just PRNG noise,
> and there is no guarantee whatsoever that the "jitter" is not the same
> for each reboot.
> 
> > > > > In short:
> > > > >
> > > > > Want better/faster entropy, use rng-tools, or choose to "trust" the
> > > > > CPU vendor if instructions are available.
> > > >
> > > > rng-tools is useless without a hwrng or jitterentropy-rngd, which does
> > > > the same thing as haveged.  So for a system without a hwrng, how
> > > > should that recommendation help an user?
> > >
> > > Maybe you should understand that not everyone needs that kinda level
> > > of entropy.
> > > If you are that concerned, use a TPM Module + rng-tools.
> > > haveged's primary concern is to speed up boot, *not* improve the random numbers,
> > > it does not tap entropy that the kernel is not using already.
> >
> > I think this is wrong.  According to [1] the kernel does not feed CPU
> > timing jitter based entropy to the entropy pool for the rng available
> > to userspace, which haveged does.
> 
> Jitter noise would be easily available in kernel, but thats difficult to account
> (how much is from outside sources, how much is deterministic).
> You should feed the kernel good entropy, the kernel runs a PRNG over it,
> if you feed the kernel stuff from a PRNG with no reasonable argumentation
> that this is raw entropy the accounting will be off.
> 
> Dont get me wrong, it's fine for most usecases, but haveged does reduce
> the quality of the entropy, and never should be your first option.
> 
> See the LWN article below [1], or Arch's page [2] on it.
> 
> Norbert
> 
> [1] - https://lwn.net/Articles/525459/
> [2] - https://wiki.archlinux.org/index.php/Haveged

Thanks for your explanations.  Especially the last lwn article puts
some more light on the whole topic.

Greets
Alex

-- 
/"\ ASCII RIBBON | ?With the first link, the chain is forged. The first
\ / CAMPAIGN     | speech censured, the first thought forbidden, the
 X  AGAINST      | first freedom denied, chains us all irrevocably.?
/ \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200630/b98179d6/attachment.asc>