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, Apr 17, 2019 at 10:38:18AM +0200, Lennart Poettering wrote:
> On Di, 16.04.19 09:06, Adam Williamson (adamwill@xxxxxxxxxxxxxxxxx) wrote:
> 
> > > I think all of these are good ideas. "No udev-settle" seems like a nice
> > > highlevel goal to shoot for.
> > >
> > > Another one I might add: "No stuck stop jobs" - it annoys me every single
> > > time when I reboot and something like rngd or conmon holds up my reboot
> > > for several minutes for no reason at all.
> >
> > I've seen the rngd stop thing, hadn't had time to investigate it yet as
> > more urgent fires keep showing up :/
> 
> What's the story anyway for rngd? Why would userspace be better at
> providing entropy to the kernel than the kernel itself? Why do we
> enable it on desktops at all, such systems should not be
> entropy-starved. Do we need this at all now that the kernel can use
> RDRAND itself?

IIUC, RDRAND exists from IvyBridge generation CPUs onwards for Intel
or EPYC CPUs for AMD. I've no idea what the story is for non-x86 CPUs
& RDRAND equivalent.

Anyway, whether we can rely on RDRAND depends on what we consider the
minimum targetted CPU models & architectures. I'm guessing that we
do intend Fedora to work correctly in CPUs predating/lacking RDRAND.

KVM guests can have a virtio-rng device provided on any architecture,
which feeds from host's /dev/urandom, but it is unfortunately fairly
rare for public cloud providers to enable it :-(

rngd includes support for the "jitter entropy" source which uses
CPU jitter to feed the RNG. At least in RHEL, this is the recommended
option when the CPUs lack RDRAND or equivalent and is why rngd
is enabled by default there. IIUC it is reading the jitter entropy
from the kernel's crypto APIs, optionally applying AES to data, and
then feeding it back into the kernel's rng pool.

> rngd runs as regular system service, hence what's the point of that
> altogether? I mean, it runs so late during boot, at a point where the
> entropy pool is full anyway, and we need the kernel's RNG much much
> earlier already (already because systemd assigns a uuid to each
> service invocation that derives from kernel RNG, and it does that
> super early). So, why run a service that is supposed to fill up the
> entropy pool at a point where we don't need it anymore, and if the
> kernel can do what it does most likely already on its own?

/dev/random can get depleted after boot. Though modern recommendation
is for apps to use /dev/urandom by default (or getrandom/getentropy
syscalls), some probably still uses /dev/random for historical baggage
reasons.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
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