We currently have a convoluted and complex selection of which random numbers to use. We can simplify this down to two functions that cover all of our use cases: 1) Randomness for crypto: this one needs to wait until the RNG is initialized. So it uses getrandom(0). If that's not available, it polls on /dev/random, and then reads from /dev/urandom. This function returns whether or not it was successful, as before. 2) Randomness for other things: this one uses getrandom(GRND_INSECURE). If it's not available it uses getrandom(GRND_NONBLOCK). And if that would block, then it falls back to /dev/urandom. And if /dev/urandom isn't available, it uses the fallback code. It never fails and doesn't return a value. These two cases match all the uses of randomness inside of systemd. I would prefer to make both of these return void, and get rid of the fallback code, and simply assert in the incredibly unlikely case that /dev/urandom doesn't exist. But Luca disagrees, so this commit attempts to instead keep case (1) returning a return value, which all the callers already check, and fix the fallback code in (2) to be less bad than before. For the less bad fallback code for (2), we now use auxval and some timestamps, together with various counters representing the invocation, hash it all together and provide the output. Provided that AT_RANDOM is secure, this construction is probably okay too, though notably it doesn't have any forward secrecy. Fortunately, it's only used by random_bytes() and not by crypto_random_bytes().
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.
