History log of /freebsd/sys/dev/random/random_harvestq.c (Results 1 – 25 of 101)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# fa8db724 18-Jul-2025 Mark Johnston <markj@FreeBSD.org>

random: Treat writes to /dev/random as separate from /entropy

RANDOM_CACHED is overloaded to refer both to entropy obtained from files
loaded by the boot loader, and entropy obtained via writes to
/

random: Treat writes to /dev/random as separate from /entropy

RANDOM_CACHED is overloaded to refer both to entropy obtained from files
loaded by the boot loader, and entropy obtained via writes to
/dev/random. Introduce a new source, RANDOM_RANDOMDEV, to refer to the
latter. This is to enable treating RANDOM_CACHED as a special case in
the NIST health test implementation.

Update the default harvest_mask in rc.conf to include RANDOM_RANDOMDEV,
preserving the old behaviour of accepting writes to /dev/random.

Bump __FreeBSD_version for modules which register a pure source, since
all of their values have now shifted.

Reviewed by: cem
MFC after: 3 months
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51155

show more ...


# f92ff797 18-Jul-2025 Mark Johnston <markj@FreeBSD.org>

random: Add NIST SP 800-90B entropy source health test implementations

This patch implements the noise source health tests described in chapter
four of NIST SP 800-90B[1]. The repetition count test

random: Add NIST SP 800-90B entropy source health test implementations

This patch implements the noise source health tests described in chapter
four of NIST SP 800-90B[1]. The repetition count test and adaptive
proportion test both help identify cases where a noise source is stuck
and generating the same output too frequently. The tests are disabled
by default, but making an implementation available may help implementors
conform to FIPS validation requirements. This implementation aims to
comply with the requirements listed in section 4.3 of the document.

To enable health testing, set the kern.random.nist_healthtest_enabled
tunable to 1. Startup testing is implemented as specified in the
document: the first 1024 samples from a source are evaluated according
to the two tests, and they are discarded. The RANDOM_CACHED and
RANDOM_PURE_VMGENID sources are excluded from testing, as they are
effectively a one-time source of entropy, and statistical testing
doesn't seem to provide much use.

Since the first 1024 samples from entropy sources are discarded by the
implementation, it is possible that we might end up with insufficient
entropy during early boot if no boot-time entropy source (i.e.,
/entropy) is provided. If this is a problem, it could be remediated by
modifying the implementation to poll applicable sources (e.g., RDRAND)
to complete startup testing quickly, rather than relying on the random
kthread.

The entry point for the tests is random_harvest_healthtest(), intended
to be called from individual CSPRNG implementations in order to leverage
their locking context, e.g., the entropy pool lock in Fortuna. The
Fortuna implementation is modified to call this entry point, mainly to
demonstrate how the health tests can be integrated.

The tests operate on the entropy buffer plus the embedded timestamp,
treating them as a single value. We could alternately apply the tests
to the buffer and timestamp separately.

The main parameters for the tests themselves are H, the expected
min-entropy of samples, and alpha, the desired false positive error
rate. This implementation selects H=1 and alpha=2^{-34}; since each
sample includes a CPU cycle counter value, it seems reasonable to expect
at least one bit of entropy from among the low bits of the
high-frequency counter present on systems where FreeBSD is commonly
deployed, and the false positive rate was somewhat arbitrarily selected;
for more details see the comment in random_healthtest_init().

When a health test fails, a message is printed to the console and the
source is disabled. On-demand testing is also supported via the
kern.random.nist_healthtest_ondemand sysctl. This can be used be an
administrator to re-enable a disabled source, following the same startup
testing mentioned above.

[1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf

Reviewed by: cem
MFC after: 3 months
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51154

show more ...


# 9940c974 07-Jul-2025 Mark Johnston <markj@FreeBSD.org>

random: Change the entropy harvest event queuing scheme

The entropy queue stores entropy gathered from environmental sources.
Periodically (every 100ms currently), the random kthread will drain this

random: Change the entropy harvest event queuing scheme

The entropy queue stores entropy gathered from environmental sources.
Periodically (every 100ms currently), the random kthread will drain this
queue and mix it into the CSPRNG's entropy pool(s).

The old scheme uses a ring buffer with a mutex to serialize producers,
while the sole consumer, the random kthread, avoids using a mutex on the
basis that no serialization is needed since nothing else is updating the
consumer index. On platforms without total store ordering, however,
this isn't sufficient: when a producer inserts a queue entry and updates
`ring.in`, there is no guarantee that the consumer will see the updated
queue entry upon observing the updated producer index. That is, the
update to `ring.in` may be visible before the updated queue entry is
visible. As a result, we could end up mixing in zero'ed queue entries,
though this race is fairly unlikely in practice given how infrequently
the kthread runs.

The easiest way to fix this is to make the kthread acquire the mutex as
well, and hold it while processing queue entries. However, this might
result in a long hold time if there are many queue entries, and we
really want the hold times to be short, e.g., to avoid delaying
interrupt processing.

We could introduce a proper MPSC queue, but this is probably
overcomplicated for a consumer which runs at 10Hz.

Instead, define two buffers, always with one designated as the "active"
buffer. Producers queue entries in the active buffer, and the kthread
uses the mutex to atomically flip the two buffers, so it can process
entries from the inactive buffer without holding the mutex. This
requires more memory, but keeps mutex hold times short and lets us keep
the queue implementation very simple.

Reviewed by: cem
MFC after: 1 month
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51112

show more ...


# 5e213d8a 03-Jul-2025 Mark Johnston <markj@FreeBSD.org>

random: Remove ARGSUSED annotations from random_harvestq.c

Such annotations are obsolete, the compiler tells us when parameters are
unused. No functional change intended.

Reviewed by: cem
MFC afte

random: Remove ARGSUSED annotations from random_harvestq.c

Such annotations are obsolete, the compiler tells us when parameters are
unused. No functional change intended.

Reviewed by: cem
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51114

show more ...


# e2a96b83 03-Jul-2025 Mark Johnston <markj@FreeBSD.org>

random: Define a macro for getting the CPU cycle count

Entropy queue entries always include the low 32 bits of a CPU cycle
count reading. Introduce a macro for this instead of hard-coding
get_cycle

random: Define a macro for getting the CPU cycle count

Entropy queue entries always include the low 32 bits of a CPU cycle
count reading. Introduce a macro for this instead of hard-coding
get_cyclecount() calls everywhere; this is handy for testing purposes
since this way, random(4)'s use of the cycle counter (e.g., the number
of bits we use) can be changed in one place.

No functional change intended.

Reviewed by: cem, delphij
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51113

show more ...


# 4b8b872a 03-Jul-2025 Mark Johnston <markj@FreeBSD.org>

random: Move entropy harvest queue lock macros to random_harvestq.c

They can't be used externally, so it makes no sense to have them in a
header. No functional change intended.

Reviewed by: cem
MF

random: Move entropy harvest queue lock macros to random_harvestq.c

They can't be used externally, so it makes no sense to have them in a
header. No functional change intended.

Reviewed by: cem
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51111

show more ...


# 6ccf1801 03-Jul-2025 Mark Johnston <markj@FreeBSD.org>

random: Replace a comment with a static assertion

No functional change intended.

Reviewed by: cem
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https:

random: Replace a comment with a static assertion

No functional change intended.

Reviewed by: cem
MFC after: 1 week
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D51110

show more ...


Revision tags: release/14.3.0-p1, release/14.2.0-p4, release/13.5.0-p2, release/14.3.0, release/13.4.0-p5, release/13.5.0-p1, release/14.2.0-p3, release/13.5.0, release/14.2.0-p2, release/14.1.0-p8, release/13.4.0-p4, release/14.1.0-p7, release/14.2.0-p1, release/13.4.0-p3, release/14.2.0
# b2f8b2dc 14-Oct-2024 Andrew Turner <andrew@FreeBSD.org>

sys: Add an SMCCC Random Number Generator driver

The Arm True Random Number Generator Firmware Interface provides a way
to query the SMCCC firmware for up to 192 bits of entropy. Use it to
provide a

sys: Add an SMCCC Random Number Generator driver

The Arm True Random Number Generator Firmware Interface provides a way
to query the SMCCC firmware for up to 192 bits of entropy. Use it to
provide another source of randomness to the kernel.

Reviewed by: cem, markm
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D46989

show more ...


# 32fce092 18-Sep-2024 Colin Percival <cperciva@FreeBSD.org>

random: Avoid magic numbers

Move RANDOM_FORTUNA_{NPOOLS,DEFPOOLSIZE} from fortuna.c to fortuna.h
and use RANDOM_FORTUNA_DEFPOOLSIZE in random_harvestq.c rather than
having a magic (albeit explained

random: Avoid magic numbers

Move RANDOM_FORTUNA_{NPOOLS,DEFPOOLSIZE} from fortuna.c to fortuna.h
and use RANDOM_FORTUNA_DEFPOOLSIZE in random_harvestq.c rather than
having a magic (albeit explained in a comment) number. The NPOOLS
value will be used in a later commit.

Reviewed by: cem
MFC after: 1 week
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D46693

show more ...


Revision tags: release/13.4.0, release/14.1.0, release/13.3.0
# fdafd315 24-Nov-2023 Warner Losh <imp@FreeBSD.org>

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...


# 9eecef05 15-Nov-2023 Andrew Turner <andrew@FreeBSD.org>

Add an Armv8 rndr random number provider

Armv8.5 adds an optional random number generator. This is implemented
as two special registers one to read a random number, the other to
re-seed the entropy

Add an Armv8 rndr random number provider

Armv8.5 adds an optional random number generator. This is implemented
as two special registers one to read a random number, the other to
re-seed the entropy pool before reading a random number. Both registers
will set the condition flags to tell the caller they can't produce a
random number in a reasonable amount of time.

Without a signal to reseed the entropy pool use the latter register
to provide random numbers to the kernel pool. If at a later time we
had a way to tell the provider if it needs to reseed or not we could
use the former.

On an Amazon AWS Graviton3 VM this never failed, however this may not
be the case on low end CPUs so retry reading the random number 10 times
before returning an error.

Reviewed by: imp, delphij (csprng)
Sponsored by: The FreeBSD Foundation
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D35411

show more ...


Revision tags: release/14.0.0
# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


Revision tags: release/13.2.0, release/12.4.0
# 0811ce57 13-Jul-2022 Colin Percival <cperciva@FreeBSD.org>

random: Ingest extra fast entropy when !seeded

We periodically ingest entropy from pollable entropy sources, but only
8 bytes at a time and only occasionally enough to feed all of Fortuna's
pools on

random: Ingest extra fast entropy when !seeded

We periodically ingest entropy from pollable entropy sources, but only
8 bytes at a time and only occasionally enough to feed all of Fortuna's
pools once per second. This can result in Fortuna remaining unseeded
for a nontrivial amount of time when there is no entropy passed in from
the boot loader, even if RDRAND is available to quickly provide a large
amount of entropy.

Detect in random_sources_feed if we are not yet seeded, and increase the
amount of immediate entropy harvesting we perform, in order to "fill"
Fortuna's entropy pools and avoid having
random: randomdev_wait_until_seeded unblock wait
stall the boot process when entropy is available.

This speeds up the FreeBSD boot in the Firecracker VM by 2.3 seconds.

Approved by: csprng (delphij)
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D35802

show more ...


# 0b040a48 06-Jun-2022 Andrew Turner <andrew@FreeBSD.org>

Fix the random source descriptions

- Add the missing RANDOM_PURE_QUALCOMM description
- Make RANDOM_PURE_VMGENID consistent with the other pure sources
by including "PURE_" in the description.

Fix the random source descriptions

- Add the missing RANDOM_PURE_QUALCOMM description
- Make RANDOM_PURE_VMGENID consistent with the other pure sources
by including "PURE_" in the description.

Approved by: csprng (cem)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35412

show more ...


Revision tags: release/13.1.0
# 5c73b3e0 17-Feb-2022 Colin Percival <cperciva@FreeBSD.org>

Add support for getting early entropy from UEFI

UEFI provides a protocol for accessing randomness. This is a good way
to gather early entropy, especially when there's no driver for the RNG
on the pl

Add support for getting early entropy from UEFI

UEFI provides a protocol for accessing randomness. This is a good way
to gather early entropy, especially when there's no driver for the RNG
on the platform (as is the case on the Marvell Armada8k (MACCHIATObin)
for now).

If the entropy_efi_seed option is enabled in loader.conf (default: YES)
obtain 2048 bytes of entropy from UEFI and pass is to the kernel as a
"module" of name "efi_rng_seed" and type "boot_entropy_platform"; if
present, ingest it into the kernel RNG.

Submitted by: Greg V
Reviewed by: markm, kevans
Approved by: csprng (markm)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D20780

show more ...


# 642701ab 03-Feb-2022 Kyle Evans <kevans@FreeBSD.org>

kern: harvest entropy from callouts

74cf7cae4d22 ("softclock: Use dedicated ithreads for running callouts.")
switched callouts away from the swi infrastructure. It turns out that
this was a major s

kern: harvest entropy from callouts

74cf7cae4d22 ("softclock: Use dedicated ithreads for running callouts.")
switched callouts away from the swi infrastructure. It turns out that
this was a major source of entropy in early boot, which we've now lost.

As a result, first boot on hardware without a 'fast' entropy source
would block waiting for fortuna to be seeded with little hope of
progressing without manual intervention.

Let's resolve it by explicitly harvesting entropy in callout_process()
if we've handled any callouts. cc/curthread/now seem to be reasonable
sources of entropy, so use those.

Discussed with: jhb (also proposed initial patch)
Reported by: many
Reviewed by: cem, markm (both csprng)
Differential Revision: https://reviews.freebsd.org/D34150

show more ...


Revision tags: release/12.3.0
# 5e79bba5 20-Sep-2021 Kyle Evans <kevans@FreeBSD.org>

kern: random: collect ~16x less from fast-entropy sources

Previously, we were collecting at a base rate of:

64 bits x 32 pools x 10 Hz = 2.5 kB/s

This change drops it to closer to 64-ish bits per

kern: random: collect ~16x less from fast-entropy sources

Previously, we were collecting at a base rate of:

64 bits x 32 pools x 10 Hz = 2.5 kB/s

This change drops it to closer to 64-ish bits per pool per second, to
work a little better with entropy providers in virtualized environments
without compromising the security goals of Fortuna.

Reviewed by: #csprng (cem, delphij, markm)
Differential Revision: https://reviews.freebsd.org/D32021

show more ...


# 6895cade 20-Sep-2021 Kyle Evans <kevans@FreeBSD.org>

kern: random: drop read_rate and associated functionality

Refer to discussion in PR 230808 for a less incomplete discussion, but
the gist of this change is that we currently collect orders of magnit

kern: random: drop read_rate and associated functionality

Refer to discussion in PR 230808 for a less incomplete discussion, but
the gist of this change is that we currently collect orders of magnitude
more entropy than we need.

The excess comes from bytes being read out of /dev/*random. The default
rate at which we collect entropy without the read_rate increase is
already more than we need to recover from a compromise of an internal
state.

Reviewed by: #csprng (cem, delphij, markm)
Differential Revision: https://reviews.freebsd.org/D32021

show more ...


Revision tags: release/13.0.0, release/12.2.0, release/11.4.0
# 97e25132 11-May-2020 John Baldwin <jhb@FreeBSD.org>

Remove ubsec(4).

This driver was previously marked for deprecation in r360710.

Approved by: csprng (cem, gordon, delphij)
Relnotes: yes
Sponsored by: Chelsio Communications
Differential Revision: h

Remove ubsec(4).

This driver was previously marked for deprecation in r360710.

Approved by: csprng (cem, gordon, delphij)
Relnotes: yes
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D24766

show more ...


# 75dfc66c 27-Feb-2020 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r358269 through r358399.


# 4312ebfe 27-Feb-2020 Pawel Biernacki <kaktus@FreeBSD.org>

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (18 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly mark

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (18 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.

This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Mark all obvious cases as MPSAFE. All entries that haven't been marked
as MPSAFE before are by default marked as NEEDGIANT

Reviewed by: cem
Approved by: csprng, kib (mentor, blanket)
Differential Revision: https://reviews.freebsd.org/D23841

show more ...


# 767991d2 01-Jan-2020 Conrad Meyer <cem@FreeBSD.org>

vmgenid(4): Integrate as a random(4) source

The number is public and has no "entropy," but should be integrated quickly
on VM rewind events to avoid duplicate sequences.

Approved by: csprng(markm)

vmgenid(4): Integrate as a random(4) source

The number is public and has no "entropy," but should be integrated quickly
on VM rewind events to avoid duplicate sequences.

Approved by: csprng(markm)
Differential Revision: https://reviews.freebsd.org/D22946

show more ...


# 374c9991 30-Dec-2019 Conrad Meyer <cem@FreeBSD.org>

random(4): Make entropy source deregistration safe

Allow loadable modules that provide random entropy source(s) to safely
unload. Prior to this change, no driver could ensure that their
random_sour

random(4): Make entropy source deregistration safe

Allow loadable modules that provide random entropy source(s) to safely
unload. Prior to this change, no driver could ensure that their
random_source structure was not being used by random_harvestq.c for any
period of time after invoking random_source_deregister().

This change converts the source_list LIST to a ConcurrencyKit CK_LIST and
uses an epoch(9) to protect typical read accesses of the list. The existing
HARVEST_LOCK spin mutex is used to safely add and remove list entries.
random_source_deregister() uses epoch_wait() to ensure no concurrent
source_list readers are accessing a random_source before freeing the list
item and returning to the caller.

Callers can safely unload immediately after random_source_deregister()
returns.

Reviewed by: markj
Approved by: csprng(markm)
Discussed with: jhb
Differential Revision: https://reviews.freebsd.org/D22489

show more ...


# 3ee1d5bb 26-Dec-2019 Conrad Meyer <cem@FreeBSD.org>

random(4): Simplify RANDOM_LOADABLE

Simplify RANDOM_LOADABLE by removing the ability to unload a LOADABLE
random(4) implementation. This allows one-time random module selection
at boot, by loader(8

random(4): Simplify RANDOM_LOADABLE

Simplify RANDOM_LOADABLE by removing the ability to unload a LOADABLE
random(4) implementation. This allows one-time random module selection
at boot, by loader(8). Swapping modules on the fly doesn't seem
especially useful.

This removes the need to hold a lock over the sleepable module calls
read_random and read_random_uio.

init/deinit have been pulled out of random_algorithm entirely. Algorithms
can run their own sysinits to initialize; deinit is removed entirely, as
algorithms can not be unloaded. Algorithms should initialize at
SI_SUB_RANDOM:SI_ORDER_SECOND. In LOADABLE systems, algorithms install
a pointer to their local random_algorithm context in p_random_alg_context at
that time.

Go ahead and const'ify random_algorithm objects; there is no need to mutate
them at runtime.

LOADABLE kernel NULL checks are removed from random_harvestq by ordering
random_harvestq initialization at SI_SUB_RANDOM:SI_ORDER_THIRD, after
algorithm init. Prior to random_harvestq init, hc_harvest_mask is zero and
no events are forwarded to algorithms; after random_harvestq init, the
relevant pointers will already have been installed.

Remove the bulk of random_infra shim wrappers and instead expose the bare
function pointers in sys/random.h. In LOADABLE systems, read_random(9) et
al are just thin shim macros around invoking the associated function
pointer. We do not provide a registration system but instead expect
LOADABLE modules to register themselves at SI_SUB_RANDOM:SI_ORDER_SECOND.
An example is provided in randomdev.c, as used in the random_fortuna.ko
module.

Approved by: csprng(markm)
Discussed with: gordon
Differential Revision: https://reviews.freebsd.org/D22512

show more ...


# b6db1cc7 22-Nov-2019 Conrad Meyer <cem@FreeBSD.org>

random(4): De-export random_sources list

The internal datastructures do not need to be visible outside of
random_harvestq, and this helps ensure they are not misused.

No functional change.

Approve

random(4): De-export random_sources list

The internal datastructures do not need to be visible outside of
random_harvestq, and this helps ensure they are not misused.

No functional change.

Approved by: csprng(delphij, markm)
Differential Revision: https://reviews.freebsd.org/D22485

show more ...


12345