Re: Can we maybe reduce the set of packages we install by default a bit?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 17 Apr 2019 15:14:54 -0400
Steve Grubb <sgrubb@xxxxxxxxxx> wrote:

> Ah...the devil is in the details. It does not credit entropy. This
> can easily be tested. systemctl stop rngd. Then open 2 terminal
> windows. In one terminal start this shell script:
> 
> #!/bin/sh
> 
> while [ 1 ]
> do
>         /bin/cat /proc/sys/kernel/random/entropy_avail
>         sleep 1
> done
> 
> Then in another:
> 
> cat /dev/random >/dev/null
> 
> After a couple seconds, hit ctl-c to kill cat. Watch what happens to
> the entropy.
> 
> I have a Kabylake system idling. It takes 3 minutes for entropy to
> get back to 3k after stopping the consumer. At that point its losing
> about as much as its gaining. If I start rngd and do the same test,
> my entropy bounces back to over 3k in less than a second. As it
> stands today, rngd has a dramatic effect on entropy.

I run a daemon that harvests entropy from the atmosphere via an rtl2832
and feeds it into the kernel via /dev/random.  And, yes it makes a big
difference to feed the entropy pool.

When random.c was rewritten to use chacha instead of the modified
mersenne twister (4.xx?), the way entropy was used changed.  It used
to bleed constantly across from the pool that is /dev/random
into /dev/urandom when it was above the threshold set in
write_wakeup_threshold.  Now, it only checks when the kernel routine
for get_random is called and reseeds if enough entropy is present.  It
always has decremented and still decrements entropy available when
it uses some. Under mersenne it used to be possible to set a timer as
well, but that went away with chacha.  I patch to enable that feature
in the new random.c, so I can reseed the chacha on a periodic interval.

The rationale for chacha was that server farms were starving for
entropy, and it is considered more robust for low entropy conditions,
at least that is what I understand from my reading.  

As far as the CPU hardware entropy generators, those are not open
source, so it is not possible to determine if they have a
backdoor.  Research has shown, however, that if any true entropy is
fed into a stream with compromised entropy, it results in a stream with
better entropy.  That is, a system using a compromised hardware
generator will have more robust entropy when combined with other
sources of entropy.  The kernel does this via a hash to smear the mix.
An attacker can no longer utilize an attack knowing the bits came from
the compromised generator.

Things like the bit bubbler are reasonably cheap (~100 dollars US) and
provide enough entropy for a small server farm.   Even the rtl2832 (~10
dollars US) provides about 90 Kbytes of entropy per second (the kernel
entropy pool is 4kB). Not enough for monte carlo simulations, but plenty
for a home system or a few servers.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux