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
merged 8 commits into from Nov 8, 2018

Conversation

2 participants
@poettering
Copy link
Member

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 poettering added the util-lib label Nov 7, 2018

poettering added some commits Nov 7, 2018

random-util: rename acquire_random_bytes() → genuine_random_bytes()
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.
random-util: handle if getrandom() returns 0
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.
random-util: change high_quality_required bool parameter into a flags…
… parameter

No change in behaviour, just some refactoring.
random-util: optionally enable blocking getrandom() behaviour
When generating the salt for the firstboot password logic, let's use
getrandom() blocking mode, and insist in the very best entropy.
random-util: introduce RANDOM_DONT_DRAIN
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().
random-util: optionally allow randomness to be generated via RDRAND
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
collisions.

@poettering poettering force-pushed the poettering:rdrand-everywhere branch from 545b170 to cc83d51 Nov 8, 2018

@keszybz
Copy link
Member

keszybz left a comment

Looks great apart from this one small thing.

Show resolved Hide resolved src/basic/random-util.c Outdated

@keszybz keszybz merged commit abdcb68 into systemd:master Nov 8, 2018

8 checks passed

LGTM analysis: C/C++ No alert changes
Details
LGTM analysis: JavaScript No code changes detected
Details
bionic-amd64 autopkgtest finished (success)
Details
bionic-arm64 autopkgtest finished (success)
Details
bionic-i386 autopkgtest finished (success)
Details
bionic-s390x autopkgtest finished (success)
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
semaphoreci The build passed on Semaphore.
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment