#
5e89e34f |
|
22-Feb-2024 |
Gordon Bergling <gbe@FreeBSD.org> |
random(4): Fix a typo in a source code comment - s/parmeter/parameter/ MFC after: 3 days
|
#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
474df59d |
|
09-Apr-2022 |
Gordon Bergling <gbe@FreeBSD.org> |
random(3): Fix a typo in a source code comment - s/psuedo/pseudo/ MFC after: 3 days
|
#
68b97d40 |
|
20-Dec-2019 |
Conrad Meyer <cem@FreeBSD.org> |
random(4): Flip default Fortuna generator over to Chacha20 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
|
#
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
|
#
403c0413 |
|
17-Jun-2019 |
Conrad Meyer <cem@FreeBSD.org> |
random(4): Add regression tests for uint128 implementation, Chacha CTR 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
|
#
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
|
#
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
|
#
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
|
#
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)
|
#
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)
|
#
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)
|
#
f8530155 |
|
26-Aug-2013 |
Mark Murray <markm@FreeBSD.org> |
Snapshot of current work; 1) Clean up namespace; only use "Yarrow" where it is Yarrow-specific or close enough to the Yarrow algorithm. For the rest use a neutral name. 2) Tidy up headers; put private stuff in private places. More could be done here. 3) Streamline the hashing/encryption; no need for a 256-bit counter; 128 bits will last for long enough. There are bits of debug code lying around; these will be removed at a later stage.
|
#
a7d5f7eb |
|
19-Oct-2010 |
Jamie Gritton <jamie@FreeBSD.org> |
A new jail(8) with a configuration file, to replace the work currently done by /etc/rc.d/jail.
|
#
d7f03759 |
|
19-Oct-2008 |
Ulf Lilleengen <lulf@FreeBSD.org> |
- Import the HEAD csup code which is the basis for the cvsmode work.
|
#
68527b3a |
|
11-Mar-2005 |
Hajimu UMEMOTO <ume@FreeBSD.org> |
stop including rijndael-api-fst.h from rijndael.h. this is required to integrate opencrypto into crypto.
|
#
e7806b4c |
|
09-Apr-2004 |
Mark Murray <markm@FreeBSD.org> |
Reorganise the entropy device so that high-yield entropy sources can more easily be used INSTEAD OF the hard-working Yarrow. The only hardware source used at this point is the one inside the VIA C3 Nehemiah (Stepping 3 and above) CPU. More sources will be added in due course. Contributions welcome!
|
#
0887c8c1 |
|
17-Nov-2003 |
Mark Murray <markm@FreeBSD.org> |
Overhaul the entropy device: o Each source gets its own queue, which is a FIFO, not a ring buffer. The FIFOs are implemented with the sys/queue.h macros. The separation is so that a low entropy/high rate source can't swamp the harvester with low-grade entropy and destroy the reseeds. o Each FIFO is limited to 256 (set as a macro, so adjustable) events queueable. Full FIFOs are ignored by the harvester. This is to prevent memory wastage, and helps to keep the kernel thread CPU usage within reasonable limits. o There is no need to break up the event harvesting into ${burst} sized chunks, so retire that feature. o Break the device away from its roots with the memory device, and allow it to get its major number automagically.
|
#
aad970f1 |
|
24-Aug-2003 |
David E. O'Brien <obrien@FreeBSD.org> |
Use __FBSDID(). Also some minor style cleanups.
|
#
b0186e2c |
|
21-Sep-2002 |
Mark Murray <markm@FreeBSD.org> |
No functional change. Fix comments and whitespace.
|
#
bbf09ad8 |
|
15-Jul-2002 |
Mark Murray <markm@FreeBSD.org> |
Upgrade the random device to use a "real" hash instead of building one out of a block cipher. This has 2 advantages: 1) The code is _much_ simpler 2) We aren't committing our security to one algorithm (much as we may think we trust AES). While I'm here, make an explicit reseed do a slow reseed instead of a fast; this is in line with what the original paper suggested.
|
#
e1199601 |
|
03-Mar-2002 |
Mark Murray <markm@FreeBSD.org> |
Massive lint-inspired cleanup. Remove unneeded includes. Deal with unused function arguments. Resolve a boatload of signed/unsigned imcompatabilities. Etc.
|
#
02c986ab |
|
09-Mar-2001 |
Mark Murray <markm@FreeBSD.org> |
Very large makeover of the /dev/random driver. o Separate the kernel stuff from the Yarrow algorithm. Yarrow is now well contained in one source file and one header. o Replace the Blowfish-based crypto routines with Rijndael-based ones. (Rijndael is the new AES algorithm). The huge improvement in Rijndael's key-agility over Blowfish means that this is an extremely dramatic improvement in speed, and makes a heck of a difference in its (lack of) CPU load. o Clean up the sysctl's. At BDE's prompting, I have gone back to static sysctls. o Bug fixes. The streamlining of the crypto stuff enabled me to find and fix some bugs. DES also found a bug in the reseed routine which is fixed. o Change the way reseeds clear "used" entropy. Previously, only the source(s) that caused a reseed were cleared. Now all sources in the relevant pool(s) are cleared. o Code tidy-up. Mostly to make it (nearly) 80-column compliant.
|
#
17c97150 |
|
26-Nov-2000 |
Mark Murray <markm@FreeBSD.org> |
Fix safety-net code. While technically a bug, I'm delighted to see that it has never (apparently) been invoked. Submitted by: ache
|
#
e73a42f8 |
|
25-Nov-2000 |
Mark Murray <markm@FreeBSD.org> |
Stop explicitly using nanotime(9) and use the new get_cyclecounter(9) call instead. This makes a pretty dramatic difference to the amount of work that the harvester needs to do - it is much friendlier on the system. (80386 and 80486 class machines will notice little, as the new get_cyclecounter() call is a wrapper round nanotime(9) for them).
|
#
a6278a2a |
|
14-Oct-2000 |
Mark Murray <markm@FreeBSD.org> |
After some complaints about the dir names, the random device is now in dirs called sys/*/random/ instead of sys/*/randomdev/*. Introduce blocking, but only at startup; the random device will block until the first reseed happens to prevent clients from using untrustworthy output. Provide a read_random() call for the rest of the kernel so that the entropy device does not need to be present. This means that things like IPX no longer need to have "device random" hardcoded into thir kernel config. The downside is that read_random() will provide very poor output until the entropy device is loaded and reseeded. It is recommended that developers do NOT use the read_random() call; instead, they should use arc4random() which internally uses read_random(). Clean up the mutex and locking code a bit; this makes it possible to unload the module again.
|
#
4a8612fd |
|
21-Sep-2000 |
Mark Murray <markm@FreeBSD.org> |
Remove unneeded includes. Submitted by: phk
|
#
4d87a031 |
|
10-Sep-2000 |
Mark Murray <markm@FreeBSD.org> |
Large upgrade to the entropy device; mainly inspired by feedback from many folk. o The reseed process is now a kthread. With SMPng, kthreads are pre-emptive, so the annoying jerkiness of the mouse is gone. o The data structures are protected by mutexes now, not splfoo()/splx(). o The cryptographic routines are broken out into their own subroutines. this facilitates review, and possible replacement if that is ever found necessary. Thanks to: kris, green, peter, jasone, grog, jhb Forgotten to thank: You know who you are; no offense intended.
|