Martin Steigerwald - 09.07.19, 11:07:
> Martin Steigerwald - 09.07.19, 10:54:
> > Martin Steigerwald - 08.07.19, 17:35:
> > > Just another reason I am happy to use sysvinit on my systems.
> > >
> > > unblock: systemd/241-4
> > > https://bugs.debian.org/929215
> > >
> > > Booting system should not depend on random numbers to be available
> > > in
> > > a large enough quantity.
> > >
> > > Granted there is a processor bug involved… but why rely on the
> > > random
> > > number generator of CPUs anyway?
> >
> > https://www.debian.org/releases/buster/amd64/release-notes/ch-inform
> > at ion.en.html#entropy-starvation
> >
> > is just so seriously broken I do not have any words for it.
> >
> > Just *booting* the system should not depend on enough entropy being
> > available. Starting services that need entropy may be delayed, but
> > just booting should not depend on entropy being available.
>
> This is enlightening:
>
> Openssh taking minutes to become available, booting takes half an hour
> ... because your server waits for a few bytes of randomness
>
> https://daniel-lange.com/archives/152-hello-buster.html
>
> According Daniel Systemd developers are basically getting it wrong to
> the maximum extent possible.

I probably better stop here, but Debian kernel developers activated
trusting RDRAND CPU randomness despite the warning of Theodore T'so, the
maintainer of the entropy gatherer in Linux.

In above blog post:

"Update: Since Linux kernel build 4.19.20-1 CONFIG_RANDOM_TRUST_CPU has
been enabled by default in Debian."

This means the default kernel may have become less secure, but it can be
disabled without recompiling the kernel. From linux-image-4.19.0-5-amd64
changelog:

linux (4.19.20-1) unstable; urgency=medium
[…]
* random: Enable RANDOM_TRUST_CPU. This can be reverted using the
kernel parameter: random.trust_cpu=off
[…]

Actually doing just that now for my Devuan based servers.

Ciao,
--
Martin