Bug#923675: Add related bug #916690 info
This is related to #916690.
getrandom() essentially blocks during many use cases where the system
does not have enough entropy. This is somewhat mitigated by the Debian
kernel now trusting the RDRAND (CONFIG_RANDOM_TRUST_CPU) for AMD64
(https://lists.debian.org/debian-devel/2019/02/msg00170.html) which has
this CPU instruction on somewhat recent hardware. Other architectures
and a number of virtualization setups on AMD64 are still running into
this issue.
The Debian Installer variant of this issue is the hardest* to solve.
So I fear we're in "add it to the release notes"-land again.
For Bullseye (or a point release) we should solve the problem more
comprehensively.
* The Debian Installer media cannot have a (carried over consecutive
boots) seed file embedded. This makes it the hardest case to solve as
one needs to "reach out" for entropy sources.
Downloading some random bytes from {random.org | random.debian.org} and
feeding to the entropy pool proper (ioctl RNDADDENTROPY) would solve
this for networked hosts, able to reach such an external entropy source.
Of course there is an attack vector added by reaching out to the net. So
this would need proper configurability to make it safe to use. Note: we
cannot use cryptography to protect this ... the PRNG is the very thing
in need of proper initialization here.
And for non-network hosts or ones shielded from the Internet and not run
in a proper data center environment (that would probably supply a
random.the-hoster.tld service) this will not improve the situation.
Thorsten Glaser (CC) has produced a prototype early-rng-init-tools (cf.
https://lists.debian.org/debian-devel/2019/02/msg00327.html) which could
be extended to try reading entropy off the network when it doesn't have
a carried-over seed (as in the Debian Installer case).
Reply to: