>On a modern linux system, s6-rc-update ends up calling getrandom(2) via
>the random_sauniquename() library function. But on embedded systems,
>and
>especially during early initialization, that is likely to block, which
>means that the entire boot process hangs.
Yes. That's a feature. You *want* random byte generation to block
until the entropy pool is filled up, else it can lead to security
issues.
>No, writing 160 bytes of crap to /dev/urandom as random_init does makes
>no difference; it does not in any way "speed up /dev/urandom
>initialization".
Indeed it doesn't, unfortunately. The point isn't to speed it up,
it's to shuffle the seed a bit more.
>And no, we cannot just make sure the kernel's random number generator
>is
>fully initialized before calling s6-rc-update, as s6-rc-update may very
>well be the one that starts the service(s) that eventually ensures this
>initialization (e.g., all the network-facing services).
And that's what I don't understand. Why are you calling s6-rc-update
as part of your boot process? s6-rc-update is designed for live
service database replacement; at boot time, you don't have anything
to replace. Isn't s6-rc-init + s6-rc enough for your booting
procedure?
As an aside, you cannot rely on network-facing services to fill up your
entropy pool. Network-facing services typically use cryptography, and
that is exactly the case where you _need_ a full entropy pool first
and working around it is a very bad idea.
>In general, none of the infrastructure utilities (skaware or otherwise)
>involved in the boot process can be allowed to make a possibly-blocking
>getrandom() call.
I agree. That is the reason why why s6-ftrigrd hardcodes the SURF PRNG
for its temporary pipe name generation:
https://git.skarnet.org/cgi-bin/cgit.cgi/s6/tree/src/libs6/ftrig1_make.c
I don't like to do this any more than is strictly necessary, because
I don't want to have to wonder about the predictability of the names;
if a program isn't part of the early boot process and has no reason
to be run before the entropy pool fills up, I'd rather rely on
randomness
given by the machine. Good, secure randomness.
I'm open to being convinced that s6-rc-update has a legit reason to be
run before the entropy pool fills up, but that's really not how I see
things; so please elaborate on why your setup is the way it is.
--
Laurent
Received on Tue Sep 26 2017 - 15:47:33 UTC