git: e9c023a47aed - stable/12 - random(4): Block read_random(9) on initial seeding
Date: Sun, 13 Feb 2022 01:22:46 UTC
The branch stable/12 has been updated by obrien:
URL: https://cgit.FreeBSD.org/src/commit/?id=e9c023a47aedb678c7fdb470f05cfed8dba2586e
commit e9c023a47aedb678c7fdb470f05cfed8dba2586e
Author: Conrad Meyer <cem@FreeBSD.org>
AuthorDate: 2019-04-15 18:40:36 +0000
Commit: David E. O'Brien <obrien@FreeBSD.org>
CommitDate: 2022-02-13 00:32:39 +0000
random(4): Block read_random(9) on initial seeding
read_random() is/was used, mostly without error checking, in a lot of
very sensitive places in the kernel -- including seeding the widely used
arc4random(9).
Most uses, especially arc4random(9), should block until the device is seeded
rather than proceeding with a bogus or empty seed. I did not spy any
obvious kernel consumers where blocking would be inappropriate (in the
sense that lack of entropy would be ok -- I did not investigate locking
angle thoroughly). In many instances, arc4random_buf(9) or that family
of APIs would be more appropriate anyway; that work was done in r345865.
A minor cleanup was made to the implementation of the READ_RANDOM function:
instead of using a variable-length array on the stack to temporarily store
all full random blocks sufficient to satisfy the requested 'len', only store
a single block on the stack. This has some benefit in terms of reducing
stack usage, reducing memcpy overhead and reducing devrandom output leakage
via the stack. Additionally, the stack block is now safely zeroed if it was
used.
One caveat of this change is that the kern.arandom sysctl no longer returns
zero bytes immediately if the random device is not seeded. This means that
FreeBSD-specific userspace applications which attempted to handle an
unseeded random device may be broken by this change. If such behavior is
needed, it can be replaced by the more portable getrandom(2) GRND_NONBLOCK
option.
On any typical FreeBSD system, entropy is persisted on read/write media and
used to seed the random device very early in boot, and blocking is never a
problem.
This change primarily impacts the behavior of /dev/random on embedded
systems with read-only media that do not configure "nodevice random". We
toggle the default from 'charge on blindly with no entropy' to 'block
indefinitely.' This default is safer, but may cause frustration. Embedded
system designers using FreeBSD have several options. The most obvious is to
plan to have a small writable NVRAM or NAND to persist entropy, like larger
systems. Early entropy can be fed from any loader, or by writing directly
to /dev/random during boot. Some embedded SoCs now provide a fast hardware
entropy source; this would also work for quickly seeding Fortuna. A 3rd
option would be creating an embedded-specific, more simplistic random
module, like that designed by DJB in [1] (this design still requires a small
rewritable media for forward secrecy). Finally, the least preferred option
might be "nodevice random", although I plan to remove this in a subsequent
revision.
To help developers emulate the behavior of these embedded systems on
ordinary workstations, the tunable kern.random.block_seeded_status was
added. When set to 1, it blocks the random device.
I attempted to document this change in random.4 and random.9 and ran into a
bunch of out-of-date or irrelevant or inaccurate content and ended up
rototilling those documents more than I intended to. Sorry. I think
they're in a better state now.
PR: 230875
Reviewed by: delphij, markm (earlier version)
Approved by: secteam(delphij), devrandom(markm)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D19744
(cherry picked from commit 13774e82285e8d5eb3afeff63760725f747f8581)
---
share/man/man4/random.4 | 345 ++++++++++++++-------------------------
share/man/man9/random.9 | 197 +++++++++++-----------
sys/dev/random/fortuna.c | 16 +-
sys/dev/random/random_harvestq.c | 5 -
sys/dev/random/random_infra.c | 20 ++-
sys/dev/random/randomdev.c | 113 ++++++++-----
sys/dev/random/randomdev.h | 2 +-
sys/kern/kern_mib.c | 11 +-
sys/libkern/arc4random.c | 32 +---
sys/sys/random.h | 6 +-
10 files changed, 329 insertions(+), 418 deletions(-)
diff --git a/share/man/man4/random.4 b/share/man/man4/random.4
index bd55e048ff40..0805be28c782 100644
--- a/share/man/man4/random.4
+++ b/share/man/man4/random.4
@@ -23,7 +23,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd August 26, 2018
+.Dd April 15, 2019
.Dt RANDOM 4
.Os
.Sh NAME
@@ -32,62 +32,43 @@
.Sh SYNOPSIS
.Cd "device random"
.Cd "options RANDOM_LOADABLE"
+.Cd "options RANDOM_ENABLE_ETHER"
.Cd "options RANDOM_ENABLE_UMA"
.Sh DESCRIPTION
The
.Nm
-device
-returns an endless supply of random bytes when read.
-It also accepts and reads data
-as any ordinary file.
+device returns an endless supply of random bytes when read.
.Pp
The generator will start in an
.Em unseeded
-state, and will block reads until
-it is seeded for the first time.
-This may cause trouble at system boot
-when keys and the like
-are generated from
-.Nm
-so steps should be taken to ensure a
-seeding as soon as possible.
-.Pp
-It is also possible
-to read random bytes
-by using the KERN_ARND sysctl.
-On the command line
-this could be done by
-.Pp
-.Dl "sysctl -x -B 16 kern.arandom"
-.Pp
-This sysctl will not return
-random bytes unless
-the
-.Nm
-device is seeded.
+state, and will block reads until it is seeded for the first time.
.Pp
-This initial seeding
-of random number generators
-is a bootstrapping problem
-that needs very careful attention.
-In some cases,
-it may be difficult
-to find enough randomness
-to seed a random number generator
-until a system is fully operational,
-but the system requires random numbers
-to become fully operational.
-It is (or more accurately should be)
-critically important that the
-.Nm
-device is seeded
-before the first time it is used.
-In the case where a dummy or "blocking-only"
-device is used,
-it is the responsibility
-of the system architect
-to ensure that no blocking reads
-hold up critical processes.
+To provide prompt access to the random device at boot time,
+.Fx
+automatically persists some entropy data in
+.Pa /boot/entropy
+for the loader to provide to the kernel.
+Additional entropy is regularly saved in
+.Pa /var/db/entropy .
+This saved entropy is sufficient to unblock the random device on devices with
+writeable media.
+.Pp
+Embedded applications without writable media must determine their own scheme
+for re-seeding the random device on boot, or accept that the device
+will remain unseeded and block reads indefinitely.
+See
+.Sx SECURITY CONSIDERATIONS
+for more detail.
+.Pp
+In addition to
+.Xr read 2 ,
+the direct output of the abstract kernel entropy device can be read with
+.Xr getrandom 2 ,
+.Xr getentropy 3 ,
+or the
+.Xr sysctl 8
+pseudo-variable
+.Va kern.arandom .
.Pp
To see the current settings of the software
.Nm
@@ -97,17 +78,20 @@ device, use the command line:
.Pp
which results in something like:
.Bd -literal -offset indent
+kern.random.block_seeded_status: 0
kern.random.fortuna.minpoolsize: 64
-kern.random.harvest.mask_symbolic: [HIGH_PERFORMANCE], ... ,CACHED
-kern.random.harvest.mask_bin: 00111111111
-kern.random.harvest.mask: 511
+kern.random.harvest.mask_symbolic: ENABLEDSOURCE,[DISABLEDSOURCE],...,CACHED
+kern.random.harvest.mask_bin: 00000010000000111011111
+kern.random.harvest.mask: 66015
+kern.random.use_chacha20_cipher: 0
kern.random.random_sources: 'Intel Secure Key RNG'
.Ed
.Pp
Other than
-.Dl kern.random.fortuna.minpoolsize
+.Va kern.random.block_seeded_status ,
+.Va kern.random.fortuna.minpoolsize ,
and
-.Dl kern.random.harvest.mask
+.Va kern.random.harvest.mask ,
all settings are read-only.
.Pp
The
@@ -137,17 +121,66 @@ and
.Va kern.random.harvest.mask_symbolic
sysctls
can be used to confirm
-that the choices are correct.
-Note that disabled items
+settings in a human readable form.
+Disabled items
in the latter item
are listed in square brackets.
See
.Xr random_harvest 9
for more on the harvesting of entropy.
+.Sh FILES
+.Bl -tag -width ".Pa /dev/urandom"
+.It Pa /dev/random
+.It Pa /dev/urandom
+.El
+.Sh SEE ALSO
+.Xr getrandom 2 ,
+.Xr arc4random 3 ,
+.Xr getentropy 3 ,
+.Xr random 3 ,
+.Xr sysctl 8 ,
+.Xr random 9
+.Rs
+.%A Ferguson
+.%A Schneier
+.%A Kohno
+.%B Cryptography Engineering
+.%I Wiley
+.%O ISBN 978-0-470-47424-2
+.Re
+.Sh HISTORY
+A
+.Nm
+device appeared in
+.Fx 2.2 .
+The implementation was changed to the
+.Em Yarrow algorithm in
+.Fx 5.0 .
+In
+.Fx 11.0 ,
+the Fortuna algorithm was introduced as the default.
+In
+.Fx 12.0 ,
+Yarrow was removed entirely.
+.Sh AUTHORS
+.An -nosplit
+The current
+.Nm
+code was authored by
+.An Mark R V Murray ,
+with significant contributions from many people.
.Pp
+The
+.Em Fortuna
+algorithm was designed by
+.An Niels Ferguson ,
+.An Bruce Schneier ,
+and
+.An Tadayoshi Kohno .
+.Sh CAVEATS
When
.Cd "options RANDOM_LOADABLE"
-is used,
+is enabled,
the
.Pa /dev/random
device is not created
@@ -155,13 +188,9 @@ until an "algorithm module"
is loaded.
The only module built by default is
.Em random_fortuna .
-The
-.Em random_yarrow
-module was removed in
-.Fx 12 .
-Note that this loadable module
-is slightly less efficient
-than its compiled-in equivalent.
+Loadable random modules
+are less efficient
+than their compiled-in equivalents.
This is because some functions
must be locked against
load and unload events,
@@ -170,174 +199,40 @@ to allow for removal.
.Pp
When
.Cd "options RANDOM_ENABLE_UMA"
-is used,
+is enabled,
the
.Pa /dev/random
device will obtain entropy
from the zone allocator.
-This is potentially very high rate,
-and if so will be of questionable use.
-If this is the case,
-use of this option
-is not recommended.
-Determining this is not trivial,
-so experimenting and measurement
-using tools such as
-.Xr dtrace 1
-will be required.
-.Sh RANDOMNESS
-The use of randomness in the field of computing
-is a rather subtle issue because randomness means
-different things to different people.
-Consider generating a password randomly,
-simulating a coin tossing experiment or
-choosing a random back-off period when a server does not respond.
-Each of these tasks requires random numbers,
-but the random numbers in each case have different requirements.
+This is a very high rate source with significant performance impact.
+Therefore, it is disabled by default.
.Pp
-Generation of passwords, session keys and the like
-requires cryptographic randomness.
-A cryptographic random number generator should be designed
-so that its output is difficult to guess,
-even if a lot of auxiliary information is known
-(such as when it was seeded, subsequent or previous output, and so on).
-On
-.Fx ,
-seeding for cryptographic random number generators is provided by the
-.Nm
-device,
-which provides real randomness.
-The
-.Xr arc4random 3
-library call provides a pseudo-random sequence
-which is generally reckoned to be suitable for
-simple cryptographic use.
-The OpenSSL library also provides functions for managing randomness
-via functions such as
-.Xr RAND_bytes 3
-and
-.Xr RAND_add 3 .
-Note that OpenSSL uses the
+When
+.Cd "options RANDOM_ENABLE_ETHER"
+is enabled, the
.Nm
-device for seeding automatically.
+device will obtain entropy from
+.Vt mbuf
+structures passing through the network stack.
+This source is both extremely expensive and a poor source of entropy, so it is
+disabled by default.
+.Sh SECURITY CONSIDERATIONS
+The initial seeding
+of random number generators
+is a bootstrapping problem
+that needs very careful attention.
+When writable media is available, the
+.Em Fortuna
+paper describes a robust system for rapidly reseeding the device.
.Pp
-Randomness for simulation is required in engineering or
-scientific software and games.
-The first requirement of these applications is
-that the random numbers produced conform to some well-known,
-usually uniform, distribution.
-The sequence of numbers should also appear numerically uncorrelated,
-as simulation often assumes independence of its random inputs.
-Often it is desirable to reproduce
-the results of a simulation exactly,
-so that if the generator is seeded in the same way,
-it should produce the same results.
-A peripheral concern for simulation is
-the speed of a random number generator.
+In some embedded cases, it may be difficult to find enough randomness to seed a
+random number generator until a system is fully operational.
+In these cases, is the responsibility of the system architect to ensure that
+blocking is acceptable, or that the random device is seeded.
+(This advice does not apply to typical consumer systems.)
.Pp
-Another issue in simulation is
-the size of the state associated with the random number generator, and
-how frequently it repeats itself.
-For example,
-a program which shuffles a pack of cards should have 52!\& possible outputs,
-which requires the random number generator to have 52!\& starting states.
-This means the seed should have at least log_2(52!) ~ 226 bits of state
-if the program is to stand a chance of outputting all possible sequences,
-and the program needs some unbiased way of generating these bits.
-Again,
-the
-.Nm
-device could be used for seeding here,
-but in practice, smaller seeds are usually considered acceptable.
-.Pp
-.Fx
-provides two families of functions which are considered
-suitable for simulation.
-The
-.Xr random 3
-family of functions provides a random integer
-between 0 to
-.if t 2\u\s731\s10\d\(mi1.
-.if n (2**31)\(mi1.
-The functions
-.Xr srandom 3 ,
-.Xr initstate 3
-and
-.Xr setstate 3
-are provided for deterministically setting
-the state of the generator and
-the function
-.Xr srandomdev 3
-is provided for setting the state via the
+To emulate embedded systems, developers may set the
+.Va kern.random.block_seeded_status
+tunable to 1 to verify boot does not require early availability of the
.Nm
device.
-The
-.Xr drand48 3
-family of functions are also provided,
-which provide random floating point numbers in various ranges.
-.Pp
-Randomness that is used for collision avoidance
-(for example, in certain network protocols)
-has slightly different semantics again.
-It is usually expected that the numbers will be uniform,
-as this produces the lowest chances of collision.
-Here again,
-the seeding of the generator is very important,
-as it is required that different instances of
-the generator produce independent sequences.
-However, the guessability or reproducibility of the sequence is unimportant,
-unlike the previous cases.
-.Pp
-.Fx
-does also provide the traditional
-.Xr rand 3
-library call,
-for compatibility purposes.
-However,
-it is known to be poor for simulation and
-absolutely unsuitable for cryptographic purposes,
-so its use is discouraged.
-.Sh FILES
-.Bl -tag -width ".Pa /dev/random"
-.It Pa /dev/random
-.El
-.Sh SEE ALSO
-.Xr arc4random 3 ,
-.Xr drand48 3 ,
-.Xr rand 3 ,
-.Xr RAND_add 3 ,
-.Xr RAND_bytes 3 ,
-.Xr random 3 ,
-.Xr sysctl 8 ,
-.Xr random 9
-.Rs
-.%A Ferguson
-.%A Schneier
-.%A Kohno
-.%B Cryptography Engineering
-.%I Wiley
-.%O ISBN 978-0-470-47424-2
-.Re
-.Sh HISTORY
-A
-.Nm
-device appeared in
-.Fx 2.2 .
-The current software implementation,
-introduced in
-.Fx 10.0 ,
-is by
-.An Mark R V Murray ,
-and is an implementation of the
-.Em Fortuna
-algorithm by Ferguson
-.Em et al .
-It replaces the previous
-.Em Yarrow
-implementation,
-introduced in
-.Fx 5.0 .
-The Yarrow algorithm
-is no longer supported
-by its authors,
-and is therefore no longer available.
diff --git a/share/man/man9/random.9 b/share/man/man9/random.9
index e2875e1798de..2e6189790412 100644
--- a/share/man/man9/random.9
+++ b/share/man/man9/random.9
@@ -26,12 +26,13 @@
.\"
.\" $FreeBSD$
.\" "
-.Dd July 16, 2015
+.Dd April 15, 2019
.Dt RANDOM 9
.Os
.Sh NAME
.Nm arc4rand ,
.Nm arc4random ,
+.Nm arc4random_buf ,
.Nm random ,
.Nm read_random ,
.Nm read_random_uio ,
@@ -39,86 +40,72 @@
.Nd supply pseudo-random numbers
.Sh SYNOPSIS
.In sys/libkern.h
+.Ft uint32_t
+.Fn arc4random "void"
.Ft void
-.Fn srandom "u_long seed"
-.Ft u_long
-.Fn random "void"
+.Fn arc4random_buf "void *ptr" "size_t len"
.Ft void
.Fn arc4rand "void *ptr" "u_int length" "int reseed"
-.Ft uint32_t
-.Fn arc4random "void"
.Pp
.In sys/random.h
-.Ft int
+.Ft void
.Fn read_random "void *buffer" "int count"
.Ft int
.Fn read_random_uio "struct uio *uio" "bool nonblock"
+.Ss LEGACY ROUTINES
+.In sys/libkern.h
+.Ft void
+.Fn srandom "u_long seed"
+.Ft u_long
+.Fn random "void"
.Sh DESCRIPTION
The
-.Fn random
-function will by default produce
-a sequence of numbers
-that can be duplicated
-by calling
-.Fn srandom
-with some constant
-as the
-.Fa seed .
-The
-.Fn srandom
-function may be called with any arbitrary
-.Fa seed
-value to get slightly more unpredictable numbers.
-It is important to remember that the
-.Fn random
-function is entirely predictable,
-and is therefore not of use where
-knowledge of the sequence of numbers
-may be of benefit to an attacker.
+.Fn arc4random
+and
+.Fn arc4random_buf
+functions will return very good quality random numbers, suited for
+security-related purposes.
+Both are wrappers around the underlying
+.Fn arc4rand
+interface.
+.Fn arc4random
+returns a 32-bit random value, while
+.Fn arc4random_buf
+fills
+.Fa ptr
+with
+.Fa len
+bytes of random data.
.Pp
The
.Fn arc4rand
-function will return very good quality random numbers,
-better suited
-for security-related purposes.
-The random numbers from
-.Fn arc4rand
-are seeded from the entropy device
-if it is available.
-Automatic reseeds happen
-after a certain timeinterval
-and after a certain number of bytes
-have been delivered.
-A forced reseed
-can be forced
-by passing a non-zero
-value in the
+CSPRNG
+is seeded from the
+.Xr random 4
+kernel abstract entropy device.
+Automatic reseeding happens at unspecified time and bytes (of output)
+intervals.
+A reseed can be forced by passing a non-zero
.Fa reseed
-argument.
+value.
.Pp
The
.Fn read_random
-function is used to return entropy directly from the entropy device
-if it has been loaded.
-If the entropy device is not loaded, then
-the
-.Fa buffer
-is ignored
-and zero is returned.
-The
+function is used to read entropy directly from the kernel abstract entropy
+device.
+.Fn read_random
+blocks if and until the entropy device is seeded.
+The provided
.Fa buffer
is filled with no more than
.Fa count
bytes.
It is strongly advised that
.Fn read_random
-is not used;
-instead use
+is not used directly;
+instead, use the
.Fn arc4rand
-unless it is
-necessary to know
-that no entropy
-has been returned.
+family of functions.
.Pp
The
.Fn read_random_uio
@@ -129,50 +116,35 @@ on
The
.Fa uio
argument points to a buffer where random data should be stored.
-This function only returns data if the random device is seeded.
-It blocks if unseeded,
-except when the
+If
.Fa nonblock
-argument is true.
+is true and the random device is not seeded, this function does not return any
+data.
+Otherwise, this function may block interruptibly until the random device is seeded.
+If the function is interrupted before the random device is seeded, no data is
+returned.
.Pp
-All the bits returned by
-.Fn random ,
-.Fn arc4rand ,
-.Fn read_random ,
-and
-.Fn read_random_uio
-are usable.
-For example,
-.Sq Li random()&01
-will produce a random binary value.
-.Pp
-The
-.Fn arc4random
-is a convenience function which calls
-.Fn arc4rand
-to return a 32 bit pseudo-random integer.
-.Sh RETURN VALUES
-The
+The legacy
.Fn random
-function uses
-a non-linear additive feedback random number generator
-employing a default table
-of size 31
-containing long integers
-to return successive pseudo-random
-numbers in the range from 0 to
-.if t 2\u\s731\s10\d\(mi1.
-.if n (2**31)\(mi1.
-The period of this random number generator
-is very large,
-approximately
-.if t 16\(mu(2\u\s731\s10\d\(mi1).
-.if n 16*((2**31)\(mi1).
-.Pp
+function will produce a sequence of numbers that can be duplicated by calling
+.Fn srandom
+with some constant as the
+.Fa seed .
+The legacy
+.Fn srandom
+function may be called with any
+.Fa seed
+value.
+It is strongly advised that the
+.Fn random
+function not be used to generate random numbers.
+See
+.Sx SECURITY CONSIDERATIONS .
+.Sh RETURN VALUES
The
.Fn arc4rand
-function uses the RC4 algorithm
-to generate successive pseudo-random bytes.
+function uses the Chacha20 algorithm to generate a pseudo-random sequence of
+bytes.
The
.Fn arc4random
function uses
@@ -191,6 +163,23 @@ the number of bytes placed in
.Fn read_random_uio
returns zero when successful,
otherwise an error code is returned.
+.Pp
+The legacy
+.Fn random
+function uses
+a non-linear additive feedback random number generator
+employing a default table
+of size 31
+containing long integers
+to return successive pseudo-random
+numbers in the range from 0 to
+.if t 2\u\s731\s10\d\(mi1.
+.if n (2**31)\(mi1.
+The period of this random number generator
+is very large,
+approximately
+.if t 16\(mu(2\u\s731\s10\d\(mi1).
+.if n 16*((2**31)\(mi1).
.Sh ERRORS
.Fn read_random_uio
may fail if:
@@ -210,3 +199,19 @@ wrote
.An Mark R V Murray
wrote
.Fn read_random .
+.Sh SECURITY CONSIDERATIONS
+Do not use
+.Fn random
+or
+.Fn srandom
+in new code.
+.Pp
+It is important to remember that the
+.Fn random
+function is entirely predictable.
+It is easy for attackers to predict future output of
+.Fn random
+by recording some generated values.
+We cannot emphasize strongly enough that
+.Fn random
+must not be used to generate values that are intended to be unpredictable.
diff --git a/sys/dev/random/fortuna.c b/sys/dev/random/fortuna.c
index e8a407525138..a6cfccaa3a1a 100644
--- a/sys/dev/random/fortuna.c
+++ b/sys/dev/random/fortuna.c
@@ -451,16 +451,22 @@ random_fortuna_read(uint8_t *buf, u_int bytecount)
RANDOM_RESEED_UNLOCK();
}
+#ifdef _KERNEL
+static bool block_seeded_status = false;
+SYSCTL_BOOL(_kern_random, OID_AUTO, block_seeded_status, CTLFLAG_RWTUN,
+ &block_seeded_status, 0,
+ "If non-zero, pretend Fortuna is in an unseeded state. By setting "
+ "this as a tunable, boot can be tested as if the random device is "
+ "unavailable.");
+#endif
+
bool
random_fortuna_seeded(void)
{
#ifdef _KERNEL
- /* When set, act as if we are not seeded. */
- KFAIL_POINT_CODE(DEBUG_FP, random_fortuna_seeded, {
- if (RETURN_VALUE != 0)
- fortuna_state.fs_counter = UINT128_ZERO;
- });
+ if (block_seeded_status)
+ return (false);
#endif
return (!uint128_is_zero(fortuna_state.fs_counter));
diff --git a/sys/dev/random/random_harvestq.c b/sys/dev/random/random_harvestq.c
index c040649c17b2..3cd82571ebc0 100644
--- a/sys/dev/random/random_harvestq.c
+++ b/sys/dev/random/random_harvestq.c
@@ -402,11 +402,6 @@ random_harvestq_prime(void *unused __unused)
if (keyfile != NULL) {
data = preload_fetch_addr(keyfile);
size = preload_fetch_size(keyfile);
- /* skip the first bit of the stash so others like arc4 can also have some. */
- if (size > RANDOM_CACHED_SKIP_START) {
- data += RANDOM_CACHED_SKIP_START;
- size -= RANDOM_CACHED_SKIP_START;
- }
/* Trim the size. If the admin has a file with a funny size, we lose some. Tough. */
size -= (size % sizeof(event.he_entropy));
if (data != NULL && size != 0) {
diff --git a/sys/dev/random/random_infra.c b/sys/dev/random/random_infra.c
index d31b84b24582..324c40dcecd4 100644
--- a/sys/dev/random/random_infra.c
+++ b/sys/dev/random/random_infra.c
@@ -57,12 +57,18 @@ struct random_algorithm *p_random_alg_context = &random_alg_context;
#if defined(RANDOM_LOADABLE)
+static void
+null_read_random(void *dummy __unused, u_int dummy2 __unused)
+{
+ panic("%s: no random module is loaded", __func__);
+}
+
struct random_readers {
int (*read_random_uio)(struct uio *, bool);
- u_int (*read_random)(void *, u_int);
+ void (*read_random)(void *, u_int);
} random_reader_context = {
(int (*)(struct uio *, bool))nullop,
- (u_int (*)(void *, u_int))nullop,
+ null_read_random,
};
struct sx randomdev_config_lock;
@@ -76,7 +82,7 @@ random_infra_sysinit(void *dummy __unused)
SYSINIT(random_device_h_init, SI_SUB_RANDOM, SI_ORDER_FIRST, random_infra_sysinit, NULL);
void
-random_infra_init(int (*p_random_read_uio)(struct uio *, bool), u_int (*p_random_read)(void *, u_int))
+random_infra_init(int (*p_random_read_uio)(struct uio *, bool), void (*p_random_read)(void *, u_int))
{
RANDOM_CONFIG_X_LOCK();
@@ -91,7 +97,7 @@ random_infra_uninit(void)
RANDOM_CONFIG_X_LOCK();
random_reader_context.read_random_uio = (int (*)(struct uio *, bool))nullop;
- random_reader_context.read_random = (u_int (*)(void *, u_int))nullop;
+ random_reader_context.read_random = null_read_random;
RANDOM_CONFIG_X_UNLOCK();
}
@@ -114,15 +120,13 @@ read_random_uio(struct uio *uio, bool nonblock)
return (retval);
}
-u_int
+void
read_random(void *buf, u_int len)
{
- u_int retval;
RANDOM_CONFIG_S_LOCK();
- retval = random_reader_context.read_random(buf, len);
+ random_reader_context.read_random(buf, len);
RANDOM_CONFIG_S_UNLOCK();
- return (retval);
}
#endif /* defined(RANDOM_LOADABLE) */
diff --git a/sys/dev/random/randomdev.c b/sys/dev/random/randomdev.c
index 94bd2f1a4147..19a73b28151a 100644
--- a/sys/dev/random/randomdev.c
+++ b/sys/dev/random/randomdev.c
@@ -63,7 +63,7 @@ __FBSDID("$FreeBSD$");
#define READ_RANDOM_UIO _read_random_uio
#define READ_RANDOM _read_random
static int READ_RANDOM_UIO(struct uio *, bool);
-static u_int READ_RANDOM(void *, u_int);
+static void READ_RANDOM(void *, u_int);
#else
#define READ_RANDOM_UIO read_random_uio
#define READ_RANDOM read_random
@@ -124,11 +124,53 @@ randomdev_read(struct cdev *dev __unused, struct uio *uio, int flags)
return (READ_RANDOM_UIO(uio, (flags & O_NONBLOCK) != 0));
}
+/*
+ * If the random device is not seeded, blocks until it is seeded.
+ *
+ * Returns zero when the random device is seeded.
+ *
+ * If the 'interruptible' parameter is true, and the device is unseeded, this
+ * routine may be interrupted. If interrupted, it will return either ERESTART
+ * or EINTR.
+ */
+#define SEEDWAIT_INTERRUPTIBLE true
+#define SEEDWAIT_UNINTERRUPTIBLE false
+static int
+randomdev_wait_until_seeded(bool interruptible)
+{
+ int error, spamcount, slpflags;
+
+ slpflags = interruptible ? PCATCH : 0;
+
+ error = 0;
+ spamcount = 0;
+ while (!p_random_alg_context->ra_seeded()) {
+ /* keep tapping away at the pre-read until we seed/unblock. */
+ p_random_alg_context->ra_pre_read();
+ /* Only bother the console every 10 seconds or so */
+ if (spamcount == 0)
+ printf("random: %s unblock wait\n", __func__);
+ spamcount = (spamcount + 1) % 100;
+ error = tsleep(&random_alg_context, slpflags, "randseed",
+ hz / 10);
+ if (error == ERESTART || error == EINTR) {
+ KASSERT(interruptible,
+ ("unexpected wake of non-interruptible sleep"));
+ break;
+ }
+ /* Squash tsleep timeout condition */
+ if (error == EWOULDBLOCK)
+ error = 0;
+ KASSERT(error == 0, ("unexpected tsleep error %d", error));
+ }
+ return (error);
+}
+
int
READ_RANDOM_UIO(struct uio *uio, bool nonblock)
{
uint8_t *random_buf;
- int error, spamcount;
+ int error;
ssize_t read_len, total_read, c;
/* 16 MiB takes about 0.08 s CPU time on my 2017 AMD Zen CPU */
#define SIGCHK_PERIOD (16 * 1024 * 1024)
@@ -140,26 +182,13 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock)
random_buf = malloc(PAGE_SIZE, M_ENTROPY, M_WAITOK);
p_random_alg_context->ra_pre_read();
error = 0;
- spamcount = 0;
/* (Un)Blocking logic */
- while (!p_random_alg_context->ra_seeded()) {
- if (nonblock) {
+ if (!p_random_alg_context->ra_seeded()) {
+ if (nonblock)
error = EWOULDBLOCK;
- break;
- }
- /* keep tapping away at the pre-read until we seed/unblock. */
- p_random_alg_context->ra_pre_read();
- /* Only bother the console every 10 seconds or so */
- if (spamcount == 0)
- printf("random: %s unblock wait\n", __func__);
- spamcount = (spamcount + 1)%100;
- error = tsleep(&random_alg_context, PCATCH, "randseed", hz/10);
- if (error == ERESTART || error == EINTR)
- break;
- /* Squash tsleep timeout condition */
- if (error == EWOULDBLOCK)
- error = 0;
- KASSERT(error == 0, ("unexpected tsleep error %d", error));
+ else
+ error = randomdev_wait_until_seeded(
+ SEEDWAIT_INTERRUPTIBLE);
}
if (error == 0) {
read_rate_increment((uio->uio_resid + sizeof(uint32_t))/sizeof(uint32_t));
@@ -210,30 +239,36 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock)
* It cannot assumed that random_buf is a multiple of
* RANDOM_BLOCKSIZE bytes.
*/
-u_int
*** 181 LINES SKIPPED ***