diff options
author | Jason A. Donenfeld <Jason@zx2c4.com> | 2022-03-07 05:36:19 +0100 |
---|---|---|
committer | Lennart Poettering <lennart@poettering.net> | 2022-03-09 14:25:15 +0100 |
commit | 31234fbeec1c4a8e500106dff4779ccaa5baef83 (patch) | |
tree | 2caa09baac541fb06e2342a2f314244f1fc35ba8 /src/test/test-random-util.c | |
parent | Packit: build SRPMs in Copr (diff) | |
download | systemd-31234fbeec1c4a8e500106dff4779ccaa5baef83.tar.xz systemd-31234fbeec1c4a8e500106dff4779ccaa5baef83.zip |
random-util: unify RANDOM_ALLOW_INSECURE and !RANDOM_BLOCK and simplify
RANDOM_BLOCK has existed for a long time, but RANDOM_ALLOW_INSECURE was
added more recently, leading to an awkward relationship between the two.
It turns out that only one, RANDOM_BLOCK, is needed.
RANDOM_BLOCK means return cryptographically secure numbers no matter
what. If it's not set, it means try to do that, but if it fails, fall
back to using unseeded randomness.
This part of falling back to unseeded randomness is the intent of
GRND_INSECURE, which is what RANDOM_ALLOW_INSECURE previously aliased.
Rather than having an additional flag for that, it makes more sense to
just use it whenever RANDOM_BLOCK is not set. This saves us the overhead
of having to open up /dev/urandom.
Additionally, when getrandom returns too little data, but not zero data,
we currently fall back to using /dev/urandom if RANDOM_BLOCK is not set.
This doesn't quite make sense, because if getrandom returned seeded data
once, then it will forever after return the same thing as whatever
/dev/urandom does. So in that case, we should just loop again.
Since there's never really a time where /dev/urandom is able to return
some easily but more with difficulty, we can also get rid of
RANDOM_EXTEND_WITH_PSEUDO. Once the RNG is initialized, bytes
should just flow normally.
This also makes RANDOM_MAY_FAIL obsolete, because the only case this ran
was where we'd fall back to /dev/urandom on old kernels and return
GRND_INSECURE bytes on new kernels. So also get rid of that flag.
Finally, since we're always able to use GRND_INSECURE on newer kernels,
and we only fall back to /dev/urandom on older kernels, also only fall
back to using RDRAND on those older kernels. There, the only reason to
have RDRAND is to avoid a kmsg entry about unseeded randomness.
The result of this commit is that we now cascade like this:
- Use getrandom(0) if RANDOM_BLOCK.
- Use getrandom(GRND_INSECURE) if !RANDOM_BLOCK.
- Use /dev/urandom if !RANDOM_BLOCK and no GRND_INSECURE support.
- Use /dev/urandom if no getrandom() support.
- Use RDRAND if we would use /dev/urandom for any of the above reasons
and RANDOM_ALLOW_RDRAND is set.
Diffstat (limited to '')
-rw-r--r-- | src/test/test-random-util.c | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/src/test/test-random-util.c b/src/test/test-random-util.c index 2b09a4513a..3426d606f4 100644 --- a/src/test/test-random-util.c +++ b/src/test/test-random-util.c @@ -24,11 +24,9 @@ static void test_genuine_random_bytes_one(RandomFlags flags) { } TEST(genuine_random_bytes) { - test_genuine_random_bytes_one(RANDOM_EXTEND_WITH_PSEUDO); test_genuine_random_bytes_one(0); test_genuine_random_bytes_one(RANDOM_BLOCK); test_genuine_random_bytes_one(RANDOM_ALLOW_RDRAND); - test_genuine_random_bytes_one(RANDOM_ALLOW_INSECURE); } TEST(pseudo_random_bytes) { |