Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prefer RDRAND over getrandom() and /dev/urandom when we don't need the very best randomness #10676

merged 8 commits into from Nov 8, 2018


Copy link

@poettering poettering commented Nov 7, 2018

This has the benefit that on x86-64 we won't drain the random pool so much.

Whenever we require randomness for the sake of keeping secrets stick to getrandom(), but for stuff such as UUID generation and seed generation for hash tables use RDRAND when it is available.

poettering added 8 commits Nov 8, 2018
It's more descriptive, since we also have a function random_bytes()
which sounds very similar.

Also rename pseudorandom_bytes() to pseudo_random_bytes(). This way the
two functions are nicely systematic, one returning genuine random bytes
and the other pseudo random ones.
This should normally not happen, but given that the man page suggests
something about this in the context of interruption, let's handle this
and propagate an I/O error.
… parameter

No change in behaviour, just some refactoring.
When generating the salt for the firstboot password logic, let's use
getrandom() blocking mode, and insist in the very best entropy.
Originally, the high_quality_required boolean argument controlled two
things: whether to extend any random data we successfully read with
pseudo-random data, and whether to return -ENODATA if we couldn't read
any data at all.

The boolean got replaced by RANDOM_EXTEND_WITH_PSEUDO, but this name
doesn't really cover the second part nicely. Moreover hiding both
changes of behaviour under a single flag is confusing. Hence, let's
split this part off under a new flag, and use it from random_bytes().
We only use this when we don't require the best randomness. The primary
usecase for this is UUID generation, as this means we don't drain
randomness from the kernel pool for them. Since UUIDs are usually not
secrets RDRAND should be goot enough for them to avoid real-life
@poettering poettering force-pushed the rdrand-everywhere branch from 545b170 to cc83d51 Nov 8, 2018
Copy link

@keszybz keszybz left a comment

Looks great apart from this one small thing.


src/basic/random-util.c Outdated Show resolved Hide resolved
@keszybz keszybz merged commit abdcb68 into systemd:master Nov 8, 2018
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants