Fixing Linux getrandom() in stable

[Russ Allbery]

Michael Biebl <biebl at debian.org> writes:
> Am 10.05.2018 um 19:22 schrieb Russ Allbery:

>> I may be misunderstanding the nature of the issue, but I believe that a
>> Type=oneshot service that runs a small C program that calls getrandom()
>> and then exit(0) when it returns would provide a useful facility.
>> krb5-kdc could then just declare a dependency on that service and
>> wouldn't be started until randomness was available.

> So we'd shift the waiting for randomness-to-be-available from one
> service to another? I don't quite see yet, where the benefit is in that.
> What's better if a wait-for-rng-ready binary blocks on getrandom()
> instead of the krb5-kdc binary itself? We wouldn't shorten the time we
> have to wait this way.

It means that the configured timeout for which it's reasonable to wait for
randomness is centralized in one service that can set that based on
understanding of what's necessary in practice, and timeouts to catch other
startup problems can remain in place for other services.  Right now, to
have krb5-kdc wait for randomness requires extending the startup timeout
of the service as a whole, thus potentially not diagnosing various other
problems that might be preventing the KDC from starting unrelated to
randomness.

It also opens the door to what I think would be the best long-term
solution (although the kernel and systemd folks may disagree with me):
having the kernel explicitly signal userspace in some way when getrandom()
is ready and exposing that in the systemd target dependency tree, so that
nothing has to poll and the dependency can be handled in the same way
that, e.g., devices appearing can be handled.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>