#
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 ...
|