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)
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)
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)
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)
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)
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)
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)
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)
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
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