#
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. 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
|
#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
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 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
|
#
767991d2 |
|
31-Dec-2019 |
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) Differential Revision: https://reviews.freebsd.org/D22946
|
#
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). 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
|
#
548dca90 |
|
20-Dec-2019 |
Conrad Meyer <cem@FreeBSD.org> |
random(4): Fortuna: Enable concurrent generation by default for 13 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
|
#
878a05a4 |
|
14-Aug-2019 |
Conrad Meyer <cem@FreeBSD.org> |
random(4): Remove "EXPERIMENTAL" verbiage from concurrent operation 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)
|
#
22eedc97 |
|
18-Jun-2019 |
Conrad Meyer <cem@FreeBSD.org> |
random(4): Fix a regression in short AES mode reads 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
|
#
179f6280 |
|
17-Jun-2019 |
Conrad Meyer <cem@FreeBSD.org> |
random(4): Fortuna: allow increased concurrency 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
|
#
d0d71d81 |
|
17-Jun-2019 |
Conrad Meyer <cem@FreeBSD.org> |
random(4): Generalize algorithm-independent APIs 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
|
#
00e0e488 |
|
23-May-2019 |
Conrad Meyer <cem@FreeBSD.org> |
random(4): deduplicate explicit_bzero() in harvest Pull the responsibility for zeroing events, which is general to any conceivable implementation of a random device algorithm, out of the algorithm-specific Fortuna code and into the callers. Most callers indirect through random_fortuna_process_event(), so add the logic there. Most callers already explicitly bzeroed the events they provided, so the logic in Fortuna was mostly redundant. Add one missing bzero in randomdev_accumulate(). Also, remove a redundant bzero in the same function -- randomdev_hash_finish() is obliged to bzero the hash state. Reviewed by: delphij Approved by: secteam(delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D20318
|
#
e8e1f0b4 |
|
13-May-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Fortuna: Fix false negatives in is_random_seeded() (1) We may have had sufficient entropy to consider Fortuna seeded, but the random_fortuna_seeded() function would produce a false negative if fs_counter was still zero. This condition could arise after random_harvestq_prime() processed the /boot/entropy file and before any read-type operation invoked "pre_read()." Fortuna's fs_counter variable is only incremented (if certain conditions are met) by reseeding, which is invoked by random_fortuna_pre_read(). is_random_seeded(9) was introduced in r346282, but the function was unused prior to r346358, which introduced this regression. The regression broke initial seeding of arc4random(9) and broke periodic reseeding[A], until something other than arc4random(9) invoked read_random(9) or read_random_uio(9) directly. (Such as userspace getrandom(2) or read(2) of /dev/random. By default, /etc/rc.d/random does this during multiuser start-up.) (2) The conditions under which Fortuna will reseed (including initial seeding) are: (a) sufficient "entropy" (by sheer byte count; default 64) is collected in the zeroth pool (of 32 pools), and (b) it has been at least 100ms since the last reseed (to prevent trivial DoS; part of FS&K design). Prior to this revision, initial seeding might have been prevented if the reseed function was invoked during the first 100ms of boot. This revision addresses both of these issues. If random_fortuna_seeded() observes a zero fs_counter, it invokes random_fortuna_pre_read() and checks again. This addresses the problem where entropy actually was sufficient, but nothing had attempted a read -> pre_read yet. The second change is to disable the 100ms reseed guard when Fortuna has never been seeded yet (fs_lasttime == 0). The guard is intended to prevent gratuitous subsequent reseeds, not initial seeding! Machines running CURRENT between r346358 and this revision are encouraged to refresh when possible. Keys generated by userspace with /dev/random or getrandom(9) during this timeframe are safe, but any long-term session keys generated by kernel arc4random consumers are potentially suspect. [A]: Broken in the sense that is_random_seeded(9) false negatives would cause arc4random(9) to (re-)seed with weak entropy (SHA256(cyclecount || FreeBSD_version)). PR: 237869 Reported by: delphij, dim Reviewed by: delphij Approved by: secteam(delphij) X-MFC-With: r346282, r346358 (if ever) Security: yes Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D20239
|
#
13774e82 |
|
15-Apr-2019 |
Conrad Meyer <cem@FreeBSD.org> |
random(4): Block read_random(9) on initial seeding read_random() is/was used, mostly without error checking, in a lot of very sensitive places in the kernel -- including seeding the widely used arc4random(9). Most uses, especially arc4random(9), should block until the device is seeded rather than proceeding with a bogus or empty seed. I did not spy any obvious kernel consumers where blocking would be inappropriate (in the sense that lack of entropy would be ok -- I did not investigate locking angle thoroughly). In many instances, arc4random_buf(9) or that family of APIs would be more appropriate anyway; that work was done in r345865. A minor cleanup was made to the implementation of the READ_RANDOM function: instead of using a variable-length array on the stack to temporarily store all full random blocks sufficient to satisfy the requested 'len', only store a single block on the stack. This has some benefit in terms of reducing stack usage, reducing memcpy overhead and reducing devrandom output leakage via the stack. Additionally, the stack block is now safely zeroed if it was used. One caveat of this change is that the kern.arandom sysctl no longer returns zero bytes immediately if the random device is not seeded. This means that FreeBSD-specific userspace applications which attempted to handle an unseeded random device may be broken by this change. If such behavior is needed, it can be replaced by the more portable getrandom(2) GRND_NONBLOCK option. On any typical FreeBSD system, entropy is persisted on read/write media and used to seed the random device very early in boot, and blocking is never a problem. This change primarily impacts the behavior of /dev/random on embedded systems with read-only media that do not configure "nodevice random". We toggle the default from 'charge on blindly with no entropy' to 'block indefinitely.' This default is safer, but may cause frustration. Embedded system designers using FreeBSD have several options. The most obvious is to plan to have a small writable NVRAM or NAND to persist entropy, like larger systems. Early entropy can be fed from any loader, or by writing directly to /dev/random during boot. Some embedded SoCs now provide a fast hardware entropy source; this would also work for quickly seeding Fortuna. A 3rd option would be creating an embedded-specific, more simplistic random module, like that designed by DJB in [1] (this design still requires a small rewritable media for forward secrecy). Finally, the least preferred option might be "nodevice random", although I plan to remove this in a subsequent revision. To help developers emulate the behavior of these embedded systems on ordinary workstations, the tunable kern.random.block_seeded_status was added. When set to 1, it blocks the random device. I attempted to document this change in random.4 and random.9 and ran into a bunch of out-of-date or irrelevant or inaccurate content and ended up rototilling those documents more than I intended to. Sorry. I think they're in a better state now. PR: 230875 Reviewed by: delphij, markm (earlier version) Approved by: secteam(delphij), devrandom(markm) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D19744
|
#
ab69c485 |
|
07-Mar-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Fortuna: Add Chacha20 as an alternative stream cipher Chacha20 with a 256 bit key and 128 bit counter size is a good match for an AES256-ICM replacement. In userspace, Chacha20 is typically marginally slower than AES-ICM on machines with AESNI intrinsics, but typically much faster than AES on machines without special intrinsics. ChaCha20 does well on typical modern architectures with SIMD instructions, which includes most types of machines FreeBSD runs on. In the kernel, we can't (or don't) make use of AESNI intrinsics for random(4) anyway. So even on amd64, using Chacha provides a modest performance improvement in random device throughput today. This change makes the stream cipher used by random(4) configurable at boot time with the 'kern.random.use_chacha20_cipher' tunable. Very rough, non-scientific measurements at the /dev/random device, on a GENERIC-NODEBUG amd64 VM with 'pv', show a factor of 2.2x higher throughput for Chacha20 over the existing AES-ICM mode. Reviewed by: delphij, markm Approved by: secteam (delphij) Differential Revision: https://reviews.freebsd.org/D19475
|
#
e66ccbea |
|
01-Mar-2019 |
Conrad Meyer <cem@FreeBSD.org> |
fortuna: Deduplicate kernel vs user includes No functional change. Reviewed by: markj, markm Approved by: secteam (delphij), core (brooks) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D19409
|
#
51c68d18 |
|
01-Mar-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Fortuna: push CTR-mode loop down into randomdev hash.h interface As a step towards adding other potential streaming ciphers. As well as just pushing the loop down into the rijndael APIs (basically 128-bit wide AES-ICM mode) to eliminate some excess explicit_bzero(). No functional change intended. Reviewed by: delphij, markm Approved by: secteam (delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D19411
|
#
9b8d0fe4 |
|
26-Oct-2018 |
Conrad Meyer <cem@FreeBSD.org> |
Fortuna: Add failpoints to simulate initial seeding conditions Set debug.fail_point.random_fortuna_pre_read=return(1) and debug.fail_point.random_fortuna_seeded=return(1) to return to unseeded status (sort of). See the Differential URL for more detail. The goal is to reproduce e.g. Lev's recent CURRENT report[1] about failing newfs arc4random(3) usage (fixed in r338542). No functional change when failpoints are not set. [1]: https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071067.html Reported by: lev Reviewed by: delphij, markm Approved by: secteam (delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D17047
|
#
7be4093a |
|
26-Oct-2018 |
Conrad Meyer <cem@FreeBSD.org> |
fortuna: Drop global lock to zero stack variables Also drop explicit zeroing of hash context -- hash finish() operation is expected to do this. PR: 230877 Suggested by: delphij@ Reviewed by: delphij, markm Approved by: secteam (delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D16986
|
#
9a884798 |
|
26-Oct-2018 |
Conrad Meyer <cem@FreeBSD.org> |
Fortuna: fix a correctness issue in reseed (fortuna_pre_read) 'i' counts the number of pools included in the array 's'. Passing 'i+1' to reseed_internal() as the number of blocks in 's' is a bogus overrun of the initialized portion of 's' -- technically UB. I found this via code inspection, referencing §9.5.2 "Pools" of the Fortuna chapter, but I would expect Coverity to notice the same issue. Unfortunately, it doesn't appear to. Reviewed by: markm Approved by: secteam (gordon) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D16985
|
#
5528565a |
|
20-Oct-2018 |
Conrad Meyer <cem@FreeBSD.org> |
Fortuna: Fix a race to prevent reseed spamming If multiple threads enter fortuna_pre_read contemporaneously, such as via read(2) or getrandom(2), they could race to check how long it has been since the last update due to a TOCTOU problem with 'now'. Here is an example problematic execution: Thread A: Thread B: now_A = getsbinuptime(); now_B = getsbinuptime(); // now_B > now_A RANDOM_RESEED_LOCK(); if (now - fs_lasttime > SBT_1S/10) { fs_lasttime = now; ... // reseed } RANDOM_RESEED_UNLOCK(); RANDOM_RESEED_LOCK(); if (now_A - fs_lasttime > SBT_1S/10) // now_A - fs_lasttime underflows fs_lasttime = now_A; ... // reseed again, despite less than 100ms elapsing } RANDOM_RESEED_UNLOCK(); To resolve the race, simply check the current time after we win the lock race. If getsbinuptime is perceived to be expensive, another option might be to just accept the race and validate that fs_lasttime isn't "in the future." (It should be within the last ~2^31 seconds out of ~2^32 seconds representable duration.) Reviewed by: delphij, markm Approved by: secteam (delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D16984
|
#
494dda45 |
|
20-Oct-2018 |
Conrad Meyer <cem@FreeBSD.org> |
Fortuna: trivial static variable cleanup Remove unnecessary use of function-local static variable. 32 bytes is small enough to live on the stack. Reviewed by: delphij, markm Approved by: secteam (delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D16937
|
#
84880efa |
|
20-Oct-2018 |
Conrad Meyer <cem@FreeBSD.org> |
Fortuna: Add trivial assert to match FS&K definition FS&K GenerateBlocks function asserts C (counter) != 0. This should also be true in our implementation. Reviewed by: delphij, markm Approved by: secteam (delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D16936
|
#
90545403 |
|
20-Oct-2018 |
Conrad Meyer <cem@FreeBSD.org> |
Fortuna: Clean up reseeding key material to closer match FS&K When reseeding, only incorporate actual key material. Do not include e.g. the derived key schedules or other AES context. I don't think the extra material was harmful here, just not beneficial. Reviewed by: delphij, markm Approved by: secteam (delphij) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D16934
|
#
19fa89e9 |
|
25-Aug-2018 |
Mark Murray <markm@FreeBSD.org> |
Remove the Yarrow PRNG algorithm option in accordance with due notice given in random(4). This includes updating of the relevant man pages, and no-longer-used harvesting parameters. Ensure that the pseudo-unit-test still does something useful, now also with the "other" algorithm instead of Yarrow. PR: 230870 Reviewed by: cem Approved by: so(delphij,gtetlow) Approved by: re(marius) Differential Revision: https://reviews.freebsd.org/D16898
|
#
27064b30 |
|
24-Aug-2018 |
Mark Murray <markm@FreeBSD.org> |
Fix braino of mine where the reseeds would happen far too often, making the kernel process way too busy. PR: 230808 Submitted by: Conrad Meyer <cem@FreeBSD.org> Reported by: Danilo Egea Gondolfo <danilo@FreeBSD.org> Reviewed by: cem,delphij Approved by: re(rgrimes) Approved by: so(delphij) MFC after: 1 Month Security: Yes Differential Revision: https://reviews.freebsd.org/D16872
|
#
58900bee |
|
06-Oct-2017 |
Conrad Meyer <cem@FreeBSD.org> |
random(4): Discard low entropy inputs The later fields of the harvest_event structure are predictable and provide little value to the entropy pool. Only feed in the relatively high entropy counter and explicit entropy buffer to increase measured input entropy. See also: https://people.freebsd.org/~jmg/vbsdcon_2017_ddfreebsdrng_slides.pdf PR: 222807 Submitted by: W. Dean Freeman <badfilemagic AT gmail.com> Reviewed by: jmg (earlier version), delphij Approved by: secteam (delphij) Obtained from: HBSD 8d809124d563937edd84c9c9d5494406e359c55c Security: no -- low entropy marginal input has no known negative affect on pool quality Differential Revision: https://reviews.freebsd.org/D12610
|
#
cef367e6 |
|
16-May-2016 |
Eitan Adler <eadler@FreeBSD.org> |
Don't repeat the the word 'the' (one manual change to fix grammar) Confirmed With: db Approved by: secteam (not really, but this is a comment typo fix)
|
#
32a71a72 |
|
02-May-2016 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
dev/random: minor spelling fixes in comments. No functional change. Reviewed by: markm Approved by: so
|
#
7b250b1e |
|
25-Apr-2016 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
dev/random: use our roundup() macro instead of re-implementing it. While here also use howmany() macro from sys/param.h No functional change. Reviewed by: markm (roundup replacement part) Approved by: so
|
#
7a3f5d11 |
|
27-Dec-2015 |
Allan Jude <allanjude@FreeBSD.org> |
Replace sys/crypto/sha2/sha2.c with lib/libmd/sha512c.c cperciva's libmd implementation is 5-30% faster The same was done for SHA256 previously in r263218 cperciva's implementation was lacking SHA-384 which I implemented, validated against OpenSSL and the NIST documentation Extend sbin/md5 to create sha384(1) Chase dependancies on sys/crypto/sha2/sha2.{c,h} and replace them with sha512{c.c,.h} Reviewed by: cperciva, des, delphij Approved by: secteam, bapt (mentor) MFC after: 2 weeks Sponsored by: ScaleEngine Inc. Differential Revision: https://reviews.freebsd.org/D3929
|
#
e866d8f0 |
|
21-Aug-2015 |
Mark Murray <markm@FreeBSD.org> |
Make the UMA harvesting go away completely if not wanted. Default to "not wanted". Provide and document the RANDOM_ENABLE_UMA option. Change RANDOM_FAST to RANDOM_UMA to clarify the harvesting. Remove RANDOM_DEBUG option, replace with SDT probes. These will be of use to folks measuring the harvesting effect when deciding whether to use RANDOM_ENABLE_UMA. Requested by: scottl and others. Approved by: so (/dev/random blanket) Differential Revision: https://reviews.freebsd.org/D3197
|
#
646041a8 |
|
17-Aug-2015 |
Mark Murray <markm@FreeBSD.org> |
Add DEV_RANDOM pseudo-option and use it to "include out" random(4) if desired. Retire randomdev_none.c and introduce random_infra.c for resident infrastructure. Completely stub out random(4) calls in the "without DEV_RANDOM" case. Add RANDOM_LOADABLE option to allow loadable Yarrow/Fortuna/LocallyWritten algorithm. Add a skeleton "other" algorithm framework for folks to add their own processing code. NIST, anyone? Retire the RANDOM_DUMMY option. Build modules for Yarrow, Fortuna and "other". Use atomics for the live entropy rate-tracking. Convert ints to bools for the 'seeded' logic. Move _write() function from the algorithm-specific areas to randomdev.c Get rid of reseed() function - it is unused. Tidy up the opt_*.h includes. Update documentation for random(4) modules. Fix test program (reviewers, please leave this). Differential Revision: https://reviews.freebsd.org/D3354 Reviewed by: wblock,delphij,jmg,bjk Approved by: so (/dev/random blanket)
|
#
f703e799 |
|
19-Jul-2015 |
Mark Murray <markm@FreeBSD.org> |
Remove out-of-date comments. Approved by: so (/dev/random blanket)
|
#
3aa77530 |
|
12-Jul-2015 |
Mark Murray <markm@FreeBSD.org> |
* Address review (and add a bit myself). - Tweek man page. - Remove all mention of RANDOM_FORTUNA. If the system owner wants YARROW or DUMMY, they ask for it, otherwise they get FORTUNA. - Tidy up headers a bit. - Tidy up declarations a bit. - Make static in a couple of places where needed. - Move Yarrow/Fortuna SYSINIT/SYSUNINIT to randomdev.c, moving us towards a single file where the algorithm context is used. - Get rid of random_*_process_buffer() functions. They were only used in one place each, and are better subsumed into those places. - Remove *_post_read() functions as they are stubs everywhere. - Assert against buffer size illegalities. - Clean up some silly code in the randomdev_read() routine. - Make the harvesting more consistent. - Make some requested argument name changes. - Tidy up and clarify a few comments. - Make some requested comment changes. - Make some requested macro changes. * NOTE: the thing calling itself a 'unit test' is not yet a proper unit test, but it helps me ensure things work. It may be a proper unit test at some time in the future, but for now please don't make any assumptions or hold any expectations. Differential Revision: https://reviews.freebsd.org/D2025 Approved by: so (/dev/random blanket)
|
#
d1b06863 |
|
30-Jun-2015 |
Mark Murray <markm@FreeBSD.org> |
Huge cleanup of random(4) code. * GENERAL - Update copyright. - Make kernel options for RANDOM_YARROW and RANDOM_DUMMY. Set neither to ON, which means we want Fortuna - If there is no 'device random' in the kernel, there will be NO random(4) device in the kernel, and the KERN_ARND sysctl will return nothing. With RANDOM_DUMMY there will be a random(4) that always blocks. - Repair kern.arandom (KERN_ARND sysctl). The old version went through arc4random(9) and was a bit weird. - Adjust arc4random stirring a bit - the existing code looks a little suspect. - Fix the nasty pre- and post-read overloading by providing explictit functions to do these tasks. - Redo read_random(9) so as to duplicate random(4)'s read internals. This makes it a first-class citizen rather than a hack. - Move stuff out of locked regions when it does not need to be there. - Trim RANDOM_DEBUG printfs. Some are excess to requirement, some behind boot verbose. - Use SYSINIT to sequence the startup. - Fix init/deinit sysctl stuff. - Make relevant sysctls also tunables. - Add different harvesting "styles" to allow for different requirements (direct, queue, fast). - Add harvesting of FFS atime events. This needs to be checked for weighing down the FS code. - Add harvesting of slab allocator events. This needs to be checked for weighing down the allocator code. - Fix the random(9) manpage. - Loadable modules are not present for now. These will be re-engineered when the dust settles. - Use macros for locks. - Fix comments. * src/share/man/... - Update the man pages. * src/etc/... - The startup/shutdown work is done in D2924. * src/UPDATING - Add UPDATING announcement. * src/sys/dev/random/build.sh - Add copyright. - Add libz for unit tests. * src/sys/dev/random/dummy.c - Remove; no longer needed. Functionality incorporated into randomdev.*. * live_entropy_sources.c live_entropy_sources.h - Remove; content moved. - move content to randomdev.[ch] and optimise. * src/sys/dev/random/random_adaptors.c src/sys/dev/random/random_adaptors.h - Remove; plugability is no longer used. Compile-time algorithm selection is the way to go. * src/sys/dev/random/random_harvestq.c src/sys/dev/random/random_harvestq.h - Add early (re)boot-time randomness caching. * src/sys/dev/random/randomdev_soft.c src/sys/dev/random/randomdev_soft.h - Remove; no longer needed. * src/sys/dev/random/uint128.h - Provide a fake uint128_t; if a real one ever arrived, we can use that instead. All that is needed here is N=0, N++, N==0, and some localised trickery is used to manufacture a 128-bit 0ULLL. * src/sys/dev/random/unit_test.c src/sys/dev/random/unit_test.h - Improve unit tests; previously the testing human needed clairvoyance; now the test will do a basic check of compressibility. Clairvoyant talent is still a good idea. - This is still a long way off a proper unit test. * src/sys/dev/random/fortuna.c src/sys/dev/random/fortuna.h - Improve messy union to just uint128_t. - Remove unneeded 'static struct fortuna_start_cache'. - Tighten up up arithmetic. - Provide a method to allow eternal junk to be introduced; harden it against blatant by compress/hashing. - Assert that locks are held correctly. - Fix the nasty pre- and post-read overloading by providing explictit functions to do these tasks. - Turn into self-sufficient module (no longer requires randomdev_soft.[ch]) * src/sys/dev/random/yarrow.c src/sys/dev/random/yarrow.h - Improve messy union to just uint128_t. - Remove unneeded 'staic struct start_cache'. - Tighten up up arithmetic. - Provide a method to allow eternal junk to be introduced; harden it against blatant by compress/hashing. - Assert that locks are held correctly. - Fix the nasty pre- and post-read overloading by providing explictit functions to do these tasks. - Turn into self-sufficient module (no longer requires randomdev_soft.[ch]) - Fix some magic numbers elsewhere used as FAST and SLOW. Differential Revision: https://reviews.freebsd.org/D2025 Reviewed by: vsevolod,delphij,rwatson,trasz,jmg Approved by: so (delphij)
|
#
8d45c8ab |
|
18-Feb-2015 |
Xin LI <delphij@FreeBSD.org> |
- fortuna.c: catch up with r278927 and fix a buffer overflow by using the temporary buffer when remaining space is not enough to hold a whole block. - yarrow.c: add a comment that we intend to change the code and remove memcpy's in the future. (*) Requested by: markm (*) Reviewed by: markm Approved by: so (self)
|
#
133cdd9e |
|
10-Nov-2014 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Constify the AES code and propagate to consumers. This allows us to update the Fortuna code to use SHAd-256 as defined in FS&K. Approved by: so (self)
|
#
02cd12d6 |
|
04-Nov-2014 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
When reseeding the DPRNG, we're supposed to hash the current key and some accumulated entropy twice and use that as the new key. Due to a typo, we were using the output of the first hash round instead of the second. Correct this, but eliminate temp[] since we can reuse hash[]. Also add comments explaining what is going on and why. Noticed by: Sami Farin <sami.farin@gmail.com> Reviewed by: markm@ Approved by: so (des)
|
#
10cb2424 |
|
30-Oct-2014 |
Mark Murray <markm@FreeBSD.org> |
This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random. This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources. The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people. The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway. Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to. My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise. My Nomex pants are on. Let the feedback commence! Reviewed by: trasz,des(partial),imp(partial?),rwatson(partial?) Approved by: so(des)
|