aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/random
Commit message (Collapse)AuthorAgeFilesLines
* armv8rng: Fix an inverted test in random_rndr_read_one()Mark Johnston2026-01-071-1/+1
| | | | | | | | | | | | | | | | | | | | | If we get a random number, the NZCV is set to 0b0000. Then "cset %w1, ne" will test whether Z == 0 and set %w1 to 1 if so. More specifically, "cset %w1, ne" maps to "csinc %w1, wzr, wzr, eq", which stores 0 in %w1 when NZCV == 0b0100 and 1 otherwise. Thus, on a successful read we expect ret != 0, so the loop condition needs to be fixed. In practice this means that we would end up trying to fetch entropy up to ten times in a row. If all attempts are successful, the last will be returned, otherwise no entropy will be returned. Reported by: Kevin Day <kevin@your.org> Reviewed by: andrew Fixes: 9eecef052155 ("Add an Armv8 rndr random number provider") MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D54259 (cherry picked from commit 93811883500b99f9f1fb4ffd6e764226d37dcfd0)
* random: Make random_source definitions constMark Johnston2025-09-216-9/+9
| | | | | | | | | | | | | We can do so trivially, so make these tables read-only. No functional change intended. Reviewed by: cem, emaste MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D52003 (cherry picked from commit d5f55356a2fbf8222fb236fe509821e12f1ea456)
* random: Change the entropy harvest event queuing schemeMark Johnston2025-08-121-57/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 (cherry picked from commit 9940c974029ba53fc00696b3fa1784725c48a9e9)
* random: Remove ARGSUSED annotations from random_harvestq.cMark Johnston2025-07-101-6/+0
| | | | | | | | | | | | | 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 (cherry picked from commit 5e213d8a7462968e10370506a4905eab0dd48e65)
* random: Define a macro for getting the CPU cycle countMark Johnston2025-07-103-7/+17
| | | | | | | | | | | | | | | | | | 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 (cherry picked from commit e2a96b83404fcee0a079a3c3adbb448b86a38d1e)
* random: Move entropy harvest queue lock macros to random_harvestq.cMark Johnston2025-07-102-4/+5
| | | | | | | | | | | | | 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 (cherry picked from commit 4b8b872a9c55c040eb83f917fc8fd2bf908b96a9)
* random: Replace a comment with a static assertionMark Johnston2025-07-101-1/+2
| | | | | | | | | | | | 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 (cherry picked from commit 6ccf1801f225a5e3e71d5b707646731542a994c7)
* armv8rng: Don't require toolchain to support FEAT_RNGJessica Clarke2024-10-211-4/+4
| | | | | | | | | We have the mechanism in place to support encoding system registers explicitly, so use that rather than requiring LLVM 13+, which breaks our current set of GitHub CI builds. Fixes: 9eecef052155 ("Add an Armv8 rndr random number provider") (cherry picked from commit 9560ac4b638edf688566f576adc65d3654f2240c)
* Add an Armv8 rndr random number providerAndrew Turner2024-10-212-0/+136
| | | | | | | | | | | | | | | | | | | | | | | | 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 (cherry picked from commit 9eecef052155646fbc5f8f533b952b372572d06a)
* random: Avoid magic numbersColin Percival2024-09-293-6/+9
| | | | | | | | | | | | | | 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 (cherry picked from commit 32fce09268ddd97efb4412529ba57293554c5985)
* random(4): Fix a typo in a source code commentGordon Bergling2024-02-251-1/+1
| | | | | | - s/parmeter/parameter/ (cherry picked from commit 5e89e34f846a233fb97302c05af5a47c694405a1)
* nehemiah RNG: Switch to using FPU_KERN_NOCTXJohn Baldwin2023-12-291-22/+2
| | | | | | | Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D41583 (cherry picked from commit 7aec088cbce8381bd5bf730419b8fdcddf43b08d)
* sys: Remove $FreeBSD$: one-line sh patternWarner Losh2023-08-161-1/+0
| | | | Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
* sys: Remove $FreeBSD$: one-line .c patternWarner Losh2023-08-1613-26/+0
| | | | Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
* sys: Remove $FreeBSD$: two-line .h patternWarner Losh2023-08-1614-28/+0
| | | | Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
* spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSDWarner Losh2023-05-1210-10/+10
| | | | | | | | | The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
* random: Ingest extra fast entropy when !seededColin Percival2022-07-201-0/+22
| | | | | | | | | | | | | | | | | | | | | 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
* Fix the random source descriptionsAndrew Turner2022-06-171-1/+2
| | | | | | | | | | - 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
* Remove checks for __GNUCLIKE_ASM assuming it is always true.John Baldwin2022-04-121-2/+0
| | | | | | | | | | | | | All supported compilers (modern versions of GCC and clang) support this. Many places didn't have an #else so would just silently do the wrong thing. Ancient versions of icc (the original motivation for this) are no longer a compiler FreeBSD supports. PR: 263102 (exp-run) Reviewed by: brooks, imp Differential Revision: https://reviews.freebsd.org/D34797
* random(3): Fix a typo in a source code commentGordon Bergling2022-04-091-1/+1
| | | | | | - s/psuedo/pseudo/ MFC after: 3 days
* Add support for getting early entropy from UEFIColin Percival2022-02-171-0/+8
| | | | | | | | | | | | | | | | | | 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
* kern: harvest entropy from calloutsKyle Evans2022-02-032-1/+5
| | | | | | | | | | | | | | | | | | | 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
* randomdev: Remove 100 ms sleep from write routineColin Percival2021-11-161-1/+0
| | | | | | | | | | | | | | | | | | This was introduced in 2014 along with the comment (which has since been deleted): /* Introduce an annoying delay to stop swamping */ Modern cryptographic random number generators can ingest arbitrarily large amounts of non-random (or even maliciously selected) input without losing their security. Depending on the number of "boot entropy files" present on the system, this can speed up the boot process by up to 1 second. Reviewed by: cem MFC ater: 1 week Sponsored by: https://www.patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D32984
* nehemiah: manually assemble xstore(-rng)Konstantin Belousov2021-10-221-1/+1
| | | | | | | | | | | It seems that clang IAS erronously adds repz prefix which should not be there. Cpu would try to store around %ecx bytes of random, while we only expect a word. PR: 259218 Reported and tested by: Dennis Clarke <dclarke@blastwave.org> Sponsored by: The FreeBSD Foundation MFC after: 1 week
* kern: random: collect ~16x less from fast-entropy sourcesKyle Evans2021-09-231-3/+23
| | | | | | | | | | | | | 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
* kern: random: drop read_rate and associated functionalityKyle Evans2021-09-233-20/+2
| | | | | | | | | | | | | | 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
* random(4) FenestrasX: Push root seed version to arc4random(3)Conrad Meyer2020-10-102-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | Push the root seed version to userspace through the VDSO page, if the RANDOM_FENESTRASX algorithm is enabled. Otherwise, there is no functional change. The mechanism can be disabled with debug.fxrng_vdso_enable=0. arc4random(3) obtains a pointer to the root seed version published by the kernel in the shared page at allocation time. Like arc4random(9), it maintains its own per-process copy of the seed version corresponding to the root seed version at the time it last rekeyed. On read requests, the process seed version is compared with the version published in the shared page; if they do not match, arc4random(3) reseeds from the kernel before providing generated output. This change does not implement the FenestrasX concept of PCPU userspace generators seeded from a per-process base generator. That change is left for future discussion/work. Reviewed by: kib (previous version) Approved by: csprng (me -- only touching FXRNG here) Differential Revision: https://reviews.freebsd.org/D22839 Notes: svn path=/head/; revision=366622
* arc4random(9): Integrate with RANDOM_FENESTRASX push-reseedConrad Meyer2020-10-106-3/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no functional change for the existing Fortuna random(4) implementation, which remains the default in GENERIC. In the FenestrasX model, when the root CSPRNG is reseeded from pools due to an (infrequent) timer, child CSPRNGs can cheaply detect this condition and reseed. To do so, they just need to track an additional 64-bit value in the associated state, and compare it against the root seed version (generation) on random reads. This revision integrates arc4random(9) into that model without substantially changing the design or implementation of arc4random(9). The motivation is that arc4random(9) is immediately reseeded when the backing random(4) implementation has additional entropy. This is arguably most important during boot, when fenestrasX is reseeding at 1, 3, 9, 27, etc., second intervals. Today, arc4random(9) has a hardcoded 300 second reseed window. Without this mechanism, if arc4random(9) gets weak entropy during initial seed (and arc4random(9) is used early in boot, so this is quite possible), it may continue to emit poorly seeded output for 5 minutes. The FenestrasX push-reseed scheme corrects consumers, like arc4random(9), as soon as possible. Reviewed by: markm Approved by: csprng (markm) Differential Revision: https://reviews.freebsd.org/D22838 Notes: svn path=/head/; revision=366621
* Add "Fenestras X" alternative /dev/random implementationConrad Meyer2020-10-109-0/+1728
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fortuna remains the default; no functional change to GENERIC. Big picture: - Scalable entropy generation with per-CPU, buffered local generators. - "Push" system for reseeding child generators when root PRNG is reseeded. (Design can be extended to arc4random(9) and userspace generators.) - Similar entropy pooling system to Fortuna, but starts with a single pool to quickly bootstrap as much entropy as possible early on. - Reseeding from pooled entropy based on time schedule. The time interval starts small and grows exponentially until reaching a cap. Again, the goal is to have the RNG state depend on as much entropy as possible quickly, but still periodically incorporate new entropy for the same reasons as Fortuna. Notable design choices in this implementation that differ from those specified in the whitepaper: - Blake2B instead of SHA-2 512 for entropy pooling - Chacha20 instead of AES-CTR DRBG - Initial seeding. We support more platforms and not all of them use loader(8). So we have to grab the initial entropy sources in kernel mode instead, as much as possible. Fortuna didn't have any mechanism for this aside from the special case of loader-provided previous-boot entropy, so most of these sources remain TODO after this commit. Reviewed by: markm Approved by: csprng (markm) Differential Revision: https://reviews.freebsd.org/D22837 Notes: svn path=/head/; revision=366620
* Use zfree() instead of explicit_bzero() and free().John Baldwin2020-06-251-2/+1
| | | | | | | | | | | | | | | In addition to reducing lines of code, this also ensures that the full allocation is always zeroed avoiding possible bugs with incorrect lengths passed to explicit_bzero(). Suggested by: cem Reviewed by: cem, delphij Approved by: csprng (cem) Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D25435 Notes: svn path=/head/; revision=362624
* Remove ubsec(4).John Baldwin2020-05-111-1/+0
| | | | | | | | | | | | 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 Notes: svn path=/head/; revision=360918
* Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (18 of many)Pawel Biernacki2020-02-274-15/+20
| | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=358379
* vmgenid(4): Integrate as a random(4) sourceConrad Meyer2020-01-012-0/+8
| | | | | | | | | | | 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 Notes: svn path=/head/; revision=356245
* random(4): Make entropy source deregistration safeConrad Meyer2019-12-301-10/+50
| | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=356194
* random(4): Simplify RANDOM_LOADABLEConrad Meyer2019-12-266-229/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=356096
* random(4): Flip default Fortuna generator over to Chacha20Conrad Meyer2019-12-201-6/+6
| | | | | | | | | | | | | | | | The implementation was landed in r344913 and has had some bake time (at least on my personal systems). There is some discussion of the motivation for defaulting to this cipher as a PRF in the commit log for r344913. As documented in that commit, administrators can retain the prior (AES-ICM) mode of operation by setting the 'kern.random.use_chacha20_cipher' tunable to 0 in loader.conf(5). Approved by: csprng(delphij, markm) Differential Revision: https://reviews.freebsd.org/D22878 Notes: svn path=/head/; revision=355949
* random(4): Fortuna: Enable concurrent generation by default for 13Conrad Meyer2019-12-201-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | Flip the knob added in r349154 to "enabled." The commit message from that revision and associated code comment describe the rationale, implementation, and motivation for the new default in detail. I have dog-fooded this configuration on my own systems for six months, for what that's worth. For end-users: the result is just as secure. The benefit is a faster, more responsive system when processes produce significant demand on random(4). As mentioned in the earlier commit, the prior behavior may be restored by setting the kern.random.fortuna.concurrent_read="0" knob in loader.conf(5). This scales the random generation side of random(4) somewhat, although there is still a global mutex being shared by all cores and rand_harvestq; the situation is generally much better than it was before on small CPU systems, but do not expect miracles on 256-core systems running 256-thread full-rate random(4) read. Work is ongoing to address both the generation-side (in more depth) and the harvest-side scaling problems. Approved by: csprng(delphij, markm) Tested by: markm Differential Revision: https://reviews.freebsd.org/D22879 Notes: svn path=/head/; revision=355930
* random(4): De-export random_sources listConrad Meyer2019-11-223-10/+8
| | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=355022
* random(4): Use ordinary sysctl definitionsConrad Meyer2019-11-221-23/+11
| | | | | | | | | | | | There's no need to dynamically populate them; the SYSCTL_ macros take care of load/unload appropriately already (and random_harvestq is 'standard' and cannot be unloaded anyway). Approved by: csprng(delphij, markm) Differential Revision: https://reviews.freebsd.org/D22484 Notes: svn path=/head/; revision=355020
* random(4): Abstract loader entropy injectionConrad Meyer2019-11-221-30/+59
| | | | | | | | | | | | | | Break random_harvestq_prime up into some logical subroutines. The goal is that it becomes easier to add other early entropy sources. While here, drop pre-12.0 compatibility logic. loader default configuration should preload the file as expeced since 12.0. Approved by: csprng(delphij, markm) Differential Revision: https://reviews.freebsd.org/D22482 Notes: svn path=/head/; revision=355018
* random(4): Remove unused definitionsConrad Meyer2019-11-221-3/+0
| | | | | | | | Approved by: csprng(gordon, markm) Differential Revision: https://reviews.freebsd.org/D22481 Notes: svn path=/head/; revision=355017
* random/ivy: Provide mechanism to read independent seed values from rdrandConrad Meyer2019-11-221-11/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On x86 platforms with the intrinsic, rdrand is a deterministic bit generator (AES-CTR) seeded from an entropic source. On x86 platforms with rdseed, it is something closer to the upstream entropic source. (There is more nuance; a block diagram is provided in [1].) On devices with rdrand and without rdseed, there is no good intrinsic for acecssing the good entropic soure directly. However, the DRBG is guaranteed to reseed every 8 kB on these platforms. As a conservative option, on such hardware we can read an extra 7.99kB samples every time we want a sample from an independent seed. As one can imagine, this drastically slows the effective read rate of RDRAND (a factor of 1024 on amd64 and 2048 on ia32). Microbenchmarks on AMD Zen (has RDSEED) show an RDRAND rate of 25 MB/s and Intel Haswell (no RDSEED) show RDRAND of 170 MB/s. This would reduce the read rate on Haswell to ~170 kB/s (at 100% CPU). random(4)'s harvestq thread periodically "feeds" from pure sources in amounts of 128-1024 bytes. On Haswell, enabling this feature increases the CPU time of RDRAND in each "feed" from approximately 0.7-6 µs to 0.7-6 ms. Because there is some performance penalty to this more conservative option, a knob is provided to enable the change. The change does not affect platforms with RDSEED. [1]: https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide#inpage-nav-4-2 Approved by: csprng(delphij, markm) Differential Revision: https://reviews.freebsd.org/D22455 Notes: svn path=/head/; revision=355014
* random/ivy: Trivial refactoringConrad Meyer2019-11-201-7/+7
| | | | | | | | | | | | | It is clearer to me to return success/error (true/false) instead of some retry count linked to the inline assembly implementation. No functional change. Approved by: core(csprng) => csprng(markm) Differential Revision: https://reviews.freebsd.org/D22454 Notes: svn path=/head/; revision=354913
* random(4): Reorder configuration of random source modulesConrad Meyer2019-08-185-63/+81
| | | | | | | | | | | | | | | | | | | Move fast entropy source registration to the earlier SI_SUB_RANDOM:SI_ORDER_FOURTH and move random_harvestq_prime after that. Relocate the registration routines out of the much later randomdev module and into random_harvestq. This is necessary for the fast random sources to actually register before we perform random_harvestq_prime() early in the kernel boot. No functional change. Reviewed by: delphij, markjm Approved by: secteam(delphij) Differential Revision: https://reviews.freebsd.org/D21308 Notes: svn path=/head/; revision=351191
* random(4): Remove "EXPERIMENTAL" verbiage from concurrent operationConrad Meyer2019-08-151-9/+105
| | | | | | | | | | | | | | | | | | | | | | | | No functional change. Add a verbose comment giving an example side-by-side comparison between the prior and Concurrent modes of Fortuna, and why one should believe they produce the same result. The intent is to flip this on by default prior to 13.0, so testing is encouraged. To enable, add the following to loader.conf: kern.random.fortuna.concurrent_read="1" The intent is also to flip the default blockcipher to the faster Chacha-20 prior to 13.0, so testing of that mode of operation is also appreciated. To enable, add the following to loader.conf: kern.random.use_chacha20_cipher="1" Approved by: secteam(implicit) Notes: svn path=/head/; revision=351062
* random(4): Fix a regression in short AES mode readsConrad Meyer2019-06-181-1/+1
| | | | | | | | | | | | | | In r349154, random device reads of size < 16 bytes (AES block size) were accidentally broken to loop forever. Correct the loop condition for small reads. Reported by: pho Reviewed by: delphij Approved by: secteam(delphij) Differential Revision: https://reviews.freebsd.org/D20686 Notes: svn path=/head/; revision=349176
* random(4): Fortuna: allow increased concurrencyConrad Meyer2019-06-175-91/+291
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add experimental feature to increase concurrency in Fortuna. As this diverges slightly from canonical Fortuna, and due to the security sensitivity of random(4), it is off by default. To enable it, set the tunable kern.random.fortuna.concurrent_read="1". The rest of this commit message describes the behavior when enabled. Readers continue to update shared Fortuna state under global mutex, as they do in the status quo implementation of the algorithm, but shift the actual PRF generation out from under the global lock. This massively reduces the CPU time readers spend holding the global lock, allowing for increased concurrency on SMP systems and less bullying of the harvestq kthread. It is somewhat of a deviation from FS&K. I think the primary difference is that the specific sequence of AES keys will differ if READ_RANDOM_UIO is accessed concurrently (as the 2nd thread to take the mutex will no longer receive a key derived from rekeying the first thread). However, I believe the goals of rekeying AES are maintained: trivially, we continue to rekey every 1MB for the statistical property; and each consumer gets a forward-secret, independent AES key for their PRF. Since Chacha doesn't need to rekey for sequences of any length, this change makes no difference to the sequence of Chacha keys and PRF generated when Chacha is used in place of AES. On a GENERIC 4-thread VM (so, INVARIANTS/WITNESS, numbers not necessarily representative), 3x concurrent AES performance jumped from ~55 MiB/s per thread to ~197 MB/s per thread. Concurrent Chacha20 at 3 threads went from roughly ~113 MB/s per thread to ~430 MB/s per thread. Prior to this change, the system was extremely unresponsive with 3-4 concurrent random readers; each thread had high variance in latency and throughput, depending on who got lucky and won the lock. "rand_harvestq" thread CPU use was high (double digits), seemingly due to spinning on the global lock. After the change, concurrent random readers and the system in general are much more responsive, and rand_harvestq CPU use dropped to basically zero. Tests are added to the devrandom suite to ensure the uint128_add64 primitive utilized by unlocked read functions to specification. Reviewed by: markm Approved by: secteam(delphij) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D20313 Notes: svn path=/head/; revision=349154
* random(4): Generalize algorithm-independent APIsConrad Meyer2019-06-176-112/+189
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At a basic level, remove assumptions about the underlying algorithm (such as output block size and reseeding requirements) from the algorithm-independent logic in randomdev.c. Chacha20 does not have many of the restrictions that AES-ICM does as a PRF (Pseudo-Random Function), because it has a cipher block size of 512 bits. The motivation is that by generalizing the API, Chacha is not penalized by the limitations of AES. In READ_RANDOM_UIO, first attempt to NOWAIT allocate a large enough buffer for the entire user request, or the maximal input we'll accept between signal checking, whichever is smaller. The idea is that the implementation of any randomdev algorithm is then free to divide up large requests in whatever fashion it sees fit. As part of this, two responsibilities from the "algorithm-generic" randomdev code are pushed down into the Fortuna ra_read implementation (and any other future or out-of-tree ra_read implementations): 1. If an algorithm needs to rekey every N bytes, it is responsible for handling that in ra_read(). (I.e., Fortuna's 1MB rekey interval for AES block generation.) 2. If an algorithm uses a block cipher that doesn't tolerate partial-block requests (again, e.g., AES), it is also responsible for handling that in ra_read(). Several APIs are changed from u_int buffer length to the more canonical size_t. Several APIs are changed from taking a blockcount to a bytecount, to permit PRFs like Chacha20 to directly generate quantities of output that are not multiples of RANDOM_BLOCKSIZE (AES block size). The Fortuna algorithm is changed to NOT rekey every 1MiB when in Chacha20 mode (kern.random.use_chacha20_cipher="1"). This is explicitly supported by the math in FS&K §9.4 (Ferguson, Schneier, and Kohno; "Cryptography Engineering"), as well as by their conclusion: "If we had a block cipher with a 256-bit [or greater] block size, then the collisions would not have been an issue at all." For now, continue to break up reads into PAGE_SIZE chunks, as they were before. So, no functional change, mostly. Reviewed by: markm Approved by: secteam(delphij) Differential Revision: https://reviews.freebsd.org/D20312 Notes: svn path=/head/; revision=349138
* random(4): Add regression tests for uint128 implementation, Chacha CTRConrad Meyer2019-06-172-2/+6
| | | | | | | | | | | | | | | | | | | | Add some basic regression tests to verify behavior of both uint128 implementations at typical boundary conditions, to run on all architectures. Test uint128 increment behavior of Chacha in keystream mode, as used by 'kern.random.use_chacha20_cipher=1' (r344913) to verify assumptions at edge cases. These assumptions are critical to the safety of using Chacha as a PRF in Fortuna (as implemented). (Chacha's use in arc4random is safe regardless of these tests, as it is limited to far less than 4 billion blocks of output in that API.) Reviewed by: markm Approved by: secteam(gordon) Differential Revision: https://reviews.freebsd.org/D20392 Notes: svn path=/head/; revision=349137
* random(4): Fix RANDOM_LOADABLE buildConrad Meyer2019-06-011-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I introduced an obvious compiler error in r346282, so this change fixes that. Unfortunately, RANDOM_LOADABLE isn't covered by our existing tinderbox, and it seems like there were existing latent linking problems. I believe these were introduced on accident in r338324 during reduction of the boolean expression(s) adjacent to randomdev.c and hash.c. It seems the RANDOM_LOADABLE build breakage has gone unnoticed for nine months. This change correctly annotates randomdev.c and hash.c with !random_loadable to match the pre-r338324 logic; and additionally updates the HWRNG drivers in MD 'files.*', which depend on random_device symbols, with !random_loadable (it is invalid for the kernel to depend on symbols from a module). (The expression for both randomdev.c and hash.c was the same, prior to r338324: "optional random random_yarrow | random !random_yarrow !random_loadable". I.e., "random && (yarrow || !loadable)." When Yarrow was removed ("yarrow := False"), the expression was incorrectly reduced to "optional random" when it should have retained "random && !loadable".) Additionally, I discovered that virtio_random was missing a MODULE_DEPEND on random_device, which breaks kld load/link of the driver on RANDOM_LOADABLE kernels. Address that issue as well. PR: 238223 Reported by: Eir Nym <eirnym AT gmail.com> Reviewed by: delphij, markm Approved by: secteam(delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D20466 Notes: svn path=/head/; revision=348489
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-03 04:07:54 +0000