2017-11-18 17:09:20 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1+ */
|
2015-04-10 22:27:10 +02:00
|
|
|
/***
|
|
|
|
This file is part of systemd.
|
|
|
|
|
|
|
|
Copyright 2010 Lennart Poettering
|
|
|
|
|
|
|
|
systemd is free software; you can redistribute it and/or modify it
|
|
|
|
under the terms of the GNU Lesser General Public License as published by
|
|
|
|
the Free Software Foundation; either version 2.1 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
systemd is distributed in the hope that it will be useful, but
|
|
|
|
WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
Lesser General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU Lesser General Public License
|
|
|
|
along with systemd; If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
***/
|
|
|
|
|
2015-11-30 21:43:37 +01:00
|
|
|
#include <elf.h>
|
2015-04-10 22:27:10 +02:00
|
|
|
#include <errno.h>
|
|
|
|
#include <fcntl.h>
|
2018-01-11 00:39:12 +01:00
|
|
|
#include <linux/random.h>
|
2015-11-30 21:43:37 +01:00
|
|
|
#include <stdbool.h>
|
2018-01-11 00:39:12 +01:00
|
|
|
#include <stdint.h>
|
2015-11-30 21:43:37 +01:00
|
|
|
#include <stdlib.h>
|
2018-01-11 00:39:12 +01:00
|
|
|
#include <string.h>
|
2015-11-30 21:43:37 +01:00
|
|
|
#include <sys/time.h>
|
|
|
|
|
2017-10-03 10:41:51 +02:00
|
|
|
#if HAVE_SYS_AUXV_H
|
2017-04-19 22:13:27 +02:00
|
|
|
# include <sys/auxv.h>
|
|
|
|
#endif
|
|
|
|
|
2017-10-03 10:41:51 +02:00
|
|
|
#if USE_SYS_RANDOM_H
|
2017-04-19 22:13:27 +02:00
|
|
|
# include <sys/random.h>
|
|
|
|
#else
|
|
|
|
# include <linux/random.h>
|
2015-06-02 11:07:39 +02:00
|
|
|
#endif
|
2015-04-10 22:27:10 +02:00
|
|
|
|
2015-10-25 13:14:12 +01:00
|
|
|
#include "fd-util.h"
|
2015-10-25 14:08:25 +01:00
|
|
|
#include "io-util.h"
|
2015-10-25 13:14:12 +01:00
|
|
|
#include "missing.h"
|
2015-04-10 22:27:10 +02:00
|
|
|
#include "random-util.h"
|
|
|
|
#include "time-util.h"
|
|
|
|
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
int acquire_random_bytes(void *p, size_t n, bool high_quality_required) {
|
2015-04-10 22:27:10 +02:00
|
|
|
static int have_syscall = -1;
|
|
|
|
|
|
|
|
_cleanup_close_ int fd = -1;
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
unsigned already_done = 0;
|
2017-07-11 10:35:47 +02:00
|
|
|
int r;
|
2015-04-10 22:27:10 +02:00
|
|
|
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
/* Gathers some randomness from the kernel. This call will never block. If
|
|
|
|
* high_quality_required, it will always return some data from the kernel,
|
|
|
|
* regardless of whether the random pool is fully initialized or not.
|
|
|
|
* Otherwise, it will return success if at least some random bytes were
|
|
|
|
* successfully acquired, and an error if the kernel has no entropy whatsover
|
|
|
|
* for us. */
|
2015-04-10 22:27:10 +02:00
|
|
|
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
/* Use the getrandom() syscall unless we know we don't have it. */
|
|
|
|
if (have_syscall != 0) {
|
2015-04-10 22:27:10 +02:00
|
|
|
r = getrandom(p, n, GRND_NONBLOCK);
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
if (r > 0) {
|
2015-04-10 22:27:10 +02:00
|
|
|
have_syscall = true;
|
2017-07-11 10:35:47 +02:00
|
|
|
if ((size_t) r == n)
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
return 0;
|
|
|
|
if (!high_quality_required) {
|
2017-08-08 16:05:29 +02:00
|
|
|
/* Fill in the remaining bytes using pseudorandom values */
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
pseudorandom_bytes((uint8_t*) p + r, n - r);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
already_done = r;
|
|
|
|
} else if (errno == ENOSYS)
|
|
|
|
/* We lack the syscall, continue with reading from /dev/urandom. */
|
|
|
|
have_syscall = false;
|
|
|
|
else if (errno == EAGAIN) {
|
|
|
|
/* The kernel has no entropy whatsoever. Let's remember to
|
|
|
|
* use the syscall the next time again though.
|
|
|
|
*
|
|
|
|
* If high_quality_required is false, return an error so that
|
|
|
|
* random_bytes() can produce some pseudorandom
|
|
|
|
* bytes. Otherwise, fall back to /dev/urandom, which we know
|
|
|
|
* is empty, but the kernel will produce some bytes for us on
|
|
|
|
* a best-effort basis. */
|
|
|
|
have_syscall = true;
|
|
|
|
|
|
|
|
if (!high_quality_required)
|
|
|
|
return -ENODATA;
|
2015-04-10 22:27:10 +02:00
|
|
|
} else
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
return -errno;
|
2015-04-10 22:27:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
fd = open("/dev/urandom", O_RDONLY|O_CLOEXEC|O_NOCTTY);
|
|
|
|
if (fd < 0)
|
|
|
|
return errno == ENOENT ? -ENOSYS : -errno;
|
|
|
|
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
return loop_read_exact(fd, (uint8_t*) p + already_done, n - already_done, true);
|
2015-04-10 22:27:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void initialize_srand(void) {
|
|
|
|
static bool srand_called = false;
|
|
|
|
unsigned x;
|
2017-10-03 10:41:51 +02:00
|
|
|
#if HAVE_SYS_AUXV_H
|
2015-04-10 22:27:10 +02:00
|
|
|
void *auxv;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if (srand_called)
|
|
|
|
return;
|
|
|
|
|
2017-10-03 10:41:51 +02:00
|
|
|
#if HAVE_SYS_AUXV_H
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
/* The kernel provides us with 16 bytes of entropy in auxv, so let's
|
|
|
|
* try to make use of that to seed the pseudo-random generator. It's
|
|
|
|
* better than nothing... */
|
2015-04-10 22:27:10 +02:00
|
|
|
|
|
|
|
auxv = (void*) getauxval(AT_RANDOM);
|
2016-01-28 17:00:38 +01:00
|
|
|
if (auxv) {
|
2017-07-11 10:36:53 +02:00
|
|
|
assert_cc(sizeof(x) <= 16);
|
2016-01-28 17:00:38 +01:00
|
|
|
memcpy(&x, auxv, sizeof(x));
|
|
|
|
} else
|
2015-04-10 22:27:10 +02:00
|
|
|
#endif
|
2016-01-28 17:00:38 +01:00
|
|
|
x = 0;
|
|
|
|
|
2015-04-10 22:27:10 +02:00
|
|
|
|
|
|
|
x ^= (unsigned) now(CLOCK_REALTIME);
|
|
|
|
x ^= (unsigned) gettid();
|
|
|
|
|
|
|
|
srand(x);
|
|
|
|
srand_called = true;
|
|
|
|
}
|
|
|
|
|
2017-06-25 23:32:53 +02:00
|
|
|
/* INT_MAX gives us only 31 bits, so use 24 out of that. */
|
|
|
|
#if RAND_MAX >= INT_MAX
|
|
|
|
# define RAND_STEP 3
|
|
|
|
#else
|
|
|
|
/* SHORT_INT_MAX or lower gives at most 15 bits, we just just 8 out of that. */
|
|
|
|
# define RAND_STEP 1
|
|
|
|
#endif
|
|
|
|
|
|
|
|
void pseudorandom_bytes(void *p, size_t n) {
|
2015-04-10 22:27:10 +02:00
|
|
|
uint8_t *q;
|
2017-06-25 23:32:53 +02:00
|
|
|
|
|
|
|
initialize_srand();
|
|
|
|
|
|
|
|
for (q = p; q < (uint8_t*) p + n; q += RAND_STEP) {
|
|
|
|
unsigned rr;
|
|
|
|
|
|
|
|
rr = (unsigned) rand();
|
|
|
|
|
|
|
|
#if RAND_STEP >= 3
|
2017-07-11 10:35:47 +02:00
|
|
|
if ((size_t) (q - (uint8_t*) p + 2) < n)
|
2017-06-25 23:32:53 +02:00
|
|
|
q[2] = rr >> 16;
|
|
|
|
#endif
|
|
|
|
#if RAND_STEP >= 2
|
2017-07-11 10:35:47 +02:00
|
|
|
if ((size_t) (q - (uint8_t*) p + 1) < n)
|
2017-06-25 23:32:53 +02:00
|
|
|
q[1] = rr >> 8;
|
|
|
|
#endif
|
|
|
|
q[0] = rr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void random_bytes(void *p, size_t n) {
|
2015-04-10 22:27:10 +02:00
|
|
|
int r;
|
|
|
|
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
r = acquire_random_bytes(p, n, false);
|
2015-04-10 22:27:10 +02:00
|
|
|
if (r >= 0)
|
|
|
|
return;
|
|
|
|
|
2017-06-25 23:32:53 +02:00
|
|
|
/* If some idiot made /dev/urandom unavailable to us, or the
|
|
|
|
* kernel has no entropy, use a PRNG instead. */
|
|
|
|
return pseudorandom_bytes(p, n);
|
2015-04-10 22:27:10 +02:00
|
|
|
}
|