On Wed, Apr 17, 2019 at 10:38:18AM +0200, Lennart Poettering wrote:
On Di, 16.04.19 09:06, Adam Williamson (adamwill(a)fedoraproject.org)
> > I think all of these are good ideas. "No udev-settle" seems like a
> > highlevel goal to shoot for.
> > Another one I might add: "No stuck stop jobs" - it annoys me every
> > 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
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
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