![[BACK]](/icons/back.gif){kind=icon}
Up to [cvs.NetBSD.org] / src / sys / dev
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
Rewrite entropy subsystem.
Primary goals:
1. Use cryptography primitives designed and vetted by cryptographers.
2. Be honest about entropy estimation.
3. Propagate full entropy as soon as possible.
4. Simplify the APIs.
5. Reduce overhead of rnd_add_data and cprng_strong.
6. Reduce side channels of HWRNG data and human input sources.
7. Improve visibility of operation with sysctl and event counters.
Caveat: rngtest is no longer used generically for RND_TYPE_RNG
rndsources. Hardware RNG devices should have hardware-specific
health tests. For example, checking for two repeated 256-bit outputs
works to detect AMD's 2019 RDRAND bug. Not all hardware RNGs are
necessarily designed to produce exactly uniform output.
ENTROPY POOL
- A Keccak sponge, with test vectors, replaces the old LFSR/SHA-1
kludge as the cryptographic primitive.
- `Entropy depletion' is available for testing purposes with a sysctl
knob kern.entropy.depletion; otherwise it is disabled, and once the
system reaches full entropy it is assumed to stay there as far as
modern cryptography is concerned.
- No `entropy estimation' based on sample values. Such `entropy
estimation' is a contradiction in terms, dishonest to users, and a
potential source of side channels. It is the responsibility of the
driver author to study the entropy of the process that generates
the samples.
- Per-CPU gathering pools avoid contention on a global queue.
- Entropy is occasionally consolidated into global pool -- as soon as
it's ready, if we've never reached full entropy, and with a rate
limit afterward. Operators can force consolidation now by running
sysctl -w kern.entropy.consolidate=1.
- rndsink(9) API has been replaced by an epoch counter which changes
whenever entropy is consolidated into the global pool.
. Usage: Cache entropy_epoch() when you seed. If entropy_epoch()
has changed when you're about to use whatever you seeded, reseed.
. Epoch is never zero, so initialize cache to 0 if you want to reseed
on first use.
. Epoch is -1 iff we have never reached full entropy -- in other
words, the old rnd_initial_entropy is (entropy_epoch() != -1) --
but it is better if you check for changes rather than for -1, so
that if the system estimated its own entropy incorrectly, entropy
consolidation has the opportunity to prevent future compromise.
- Sysctls and event counters provide operator visibility into what's
happening:
. kern.entropy.needed - bits of entropy short of full entropy
. kern.entropy.pending - bits known to be pending in per-CPU pools,
can be consolidated with sysctl -w kern.entropy.consolidate=1
. kern.entropy.epoch - number of times consolidation has happened,
never 0, and -1 iff we have never reached full entropy
CPRNG_STRONG
- A cprng_strong instance is now a collection of per-CPU NIST
Hash_DRBGs. There are only two in the system: user_cprng for
/dev/urandom and sysctl kern.?random, and kern_cprng for kernel
users which may need to operate in interrupt context up to IPL_VM.
(Calling cprng_strong in interrupt context does not strike me as a
particularly good idea, so I added an event counter to see whether
anything actually does.)
- Event counters provide operator visibility into when reseeding
happens.
INTEL RDRAND/RDSEED, VIA C3 RNG (CPU_RNG)
- Unwired for now; will be rewired in a subsequent commit.
Mostly merge changes from HEAD upto 20200411
Pull up following revision(s) (requested by riastradh in ticket #1705): sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal cprng.h: use static __inline for consistency with other include headers and remove an unused function. - Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
Pull up following revision(s) (requested by riastradh in ticket #1705): sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal cprng.h: use static __inline for consistency with other include headers and remove an unused function. - Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
Pull up following revision(s) (requested by riastradh in ticket #1705): sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal cprng.h: use static __inline for consistency with other include headers and remove an unused function. - Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
Pull up following revision(s) (requested by riastradh in ticket #1365): sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.13 - 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal cprng.h: use static __inline for consistency with other include headers and remove an unused function. - Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away...
Pull up following revision(s) (requested by riastradh in ticket #173): sys/crypto/nist_hash_drbg/nist_hash_drbg.c: revision 1.1 sys/crypto/nist_hash_drbg/nist_hash_drbg.h: revision 1.1 sys/rump/kern/lib/libcrypto/Makefile: revision 1.5 sys/crypto/nist_hash_drbg/files.nist_hash_drbg: revision 1.1 sys/rump/librump/rumpkern/Makefile.rumpkern: revision 1.176 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes256.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_drbg_config.h: file removal sys/conf/files: revision 1.1238 sys/dev/rndpseudo.c: revision 1.38 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.c: file removal sys/sys/cprng.h: revision 1.15 sys/crypto/nist_ctr_drbg/nist_ctr_drbg.h: file removal sys/crypto/nist_ctr_drbg/nist_ctr_aes_rijndael.h: file removal sys/crypto/nist_ctr_drbg/files.nist_ctr_drbg: file removal sys/kern/subr_cprng.c: revision 1.31 sys/crypto/nist_ctr_drbg/nist_ctr_drbg_aes128.h: file removal Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (<a rel="nofollow" href="https://eprint.iacr.org/2018/349">https://eprint.iacr.org/2018/349</a>) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away... XXX pullup-7 XXX pullup-8 XXX pullup-9
Switch from NIST CTR_DRBG with AES to NIST Hash_DRBG with SHA-256. Benefits: - larger seeds -- a 128-bit key alone is not enough for `128-bit security' - better resistance to timing side channels than AES - a better-understood security story (https://eprint.iacr.org/2018/349) - no loss in compliance with US government standards that nobody ever got fired for choosing, at least in the US-dominated western world - no dirty endianness tricks - self-tests Drawbacks: - performance hit: throughput is reduced to about 1/3 in naive measurements => possible to mitigate by using hardware SHA-256 instructions => all you really need is 32 bytes to seed a userland PRNG anyway => if we just used ChaCha this would go away... XXX pullup-7 XXX pullup-8 XXX pullup-9
Sync with HEAD
Sync with HEAD Resolve a couple of conflicts (result of the uimin/uimax changes)
Rename min/max -> uimin/uimax for better honesty. These functions are defined on unsigned int. The generic name min/max should not silently truncate to 32 bits on 64-bit systems. This is purely a name change -- no functional change intended. HOWEVER! Some subsystems have #define min(a, b) ((a) < (b) ? (a) : (b)) #define max(a, b) ((a) > (b) ? (a) : (b)) even though our standard name for that is MIN/MAX. Although these may invite multiple evaluation bugs, these do _not_ cause integer truncation. To avoid `fixing' these cases, I first changed the name in libkern, and then compile-tested every file where min/max occurred in order to confirm that it failed -- and thus confirm that nothing shadowed min/max -- before changing it. I have left a handful of bootloaders that are too annoying to compile-test, and some dead code: cobalt ews4800mips hp300 hppa ia64 luna68k vax acorn32/if_ie.c (not included in any kernels) macppc/if_gm.c (superseded by gem(4)) It should be easy to fix the fallout once identified -- this way of doing things fails safe, and the goal here, after all, is to _avoid_ silent integer truncations, not introduce them. Maybe one day we can reintroduce min/max as type-generic things that never silently truncate. But we should avoid doing that for a while, so that existing code has a chance to be detected by the compiler for conversion to uimin/uimax without changing the semantics until we can properly audit it all. (Who knows, maybe in some cases integer truncation is actually intended!)
Apply patch (requested by riastradh in ticket #1512): Fix panic when waiting with kqueue/kevent for a read from /dev/random.
Apply patch (requested by riastradh in ticket #1512): Fix panic when waiting with kqueue/kevent for a read from /dev/random.
Apply patch (requested by riastradh in ticket #1512): Fix panic when waiting with kqueue/kevent for a read from /dev/random.
update from HEAD
add fo_name so we can identify the fileops in a simple way.
Remove more unnecessary #include for sys/localcount.h
Restore all work from the former pgoyette-localcount branch (which is now abandoned doe to cvs merge botch). The branch now builds, and installs via anita. There are still some problems (cgd is non-functional and all atf tests time-out) but they will get resolved soon.
Rename LOCALCOUNT_INITIALIZER to DEVSW_MODULE_INIT. This better describes what we're doing, and why.
Instead of repeatedly typing the conditional initialization of the
.d_localcount members in the various {b,c}devsw, define an initializer
macro and use it. This also removes the need for defining new symbols
for each 'struct localcount'.
As suggested by riastradh@
Rump drivers are always installed via devsw_attach() so we need to always allocate a 'struct localcount' for these drivers whenever they are built as modules.
Sync with HEAD
include "ioconf.h" to get the 'void <driver>attach(int count);' prototype.
Sync with HEAD
Mark some variables __read_mostly.
Sort includes.
Xor, not ior, to combine bits of binuptime for rnd_counter.
Move substantive part of rnd_ioctl to kern_rndq.c.
Eliminate last two cases of u_int*_t in rndpseudo.c.
Use binuptime, not microtime/nanotime as substitute cycle counter.
Include rndpool.h, rndsource.h here because we use them.
Use rnd_add_data, not rndpool_mtx and rndpool_add_data.
Gather rnd-private declarations into <dev/rnd_private.h>. Let's try to avoid putting externs in .c files where the compiler can't check them.
If we're going to use the queue macros, use them as intended.
add a couple of event counters.
Pull up following revision(s) (requested by tls in ticket #173): doc/CHANGES: revision 1.2004 sys/sys/rnd.h: revision 1.43 sys/kern/kern_rndq.c: revision 1.28 sys/kern/kern_rndsink.c: revision 1.10 sys/dev/rndpseudo.c: revision 1.23 Fixes and enhancements for polled entropy sources: Add explicit enable/disable hooks for callout-driven sources (be more power friendly). Make "skew" source polled so it runs only when there is entropy demand. Adjust entropy collection from polled sources so it's processed sooner.
Fixes and enhancements for polled entropy sources: Add explicit enable/disable hooks for callout-driven sources (be more power friendly). Make "skew" source polled so it runs only when there is entropy demand. Adjust entropy collection from polled sources so it's processed sooner.
Try not to use f_data, use f_rndctx to get a correctly typed pointer.
Rebase to HEAD as of a few days ago.
Merge tls-earlyentropy branch into HEAD.
Rebase.
Add d_discard to all struct cdevsw instances I could find. All have been set to "nodiscard"; some should get a real implementation.
Adjustments to the "earlyentropy" branch in response to the various discussions beginning with my initial proposal http://mail-index.netbsd.org/tech-kern/2014/04/08/msg016876.html and particularly the long discussion of cprng_fast() performance (e.g. https://mail-index.netbsd.org/tech-crypto/2014/04/21/msg000642.html). In particular: * Per-CPU, lockless cprng_fast replacement using Dennis Ferguson's "ccrand" implementation of ChaCha8. * libkern arc4random() is gone, gone, gone. * Entropy estimator reverted to 32-bit recordkeeping and timestamps per Dennis' comments and analysis. * LZF entropy estimator removed: it required a great deal of state, and rejected only truly pathological input. I have not yet reverted the changes that provide LZF in the kernel as generic functionality; I will likely revert those changes prior to any merge of this branch to HEAD.
sync with head.
for a reference, the tree before this commit was tagged
as yamt-pagecache-tag8.
this commit was splitted into small chunks to avoid
a limitation of cvs. ("Protocol error: too many arguments")
sync with head
Whups. It'd help to check in the ioctl changes needed to support that rndctl change just prior... ;-)
Change (mostly mechanically) every cdevsw/bdevsw I can find to use designated initializers. I have not built every extant kernel so I have probably broken at least one build; however I've also found and fixed some wrong cdevsw/bdevsw entries so even if so I think we come out ahead.
kill _RUMPKERNEL ifdef
Fix spurious kassert on interrupted blocking read from /dev/random. Return EINTR in this case instead. While here, clarify comment. Fixes PR kern/48119, simpler than the patch attached there, per discussion with tls@, who had this right in the earlier version of rndpseudo.c before I broke it (oops!).
sync with head
sync with HEAD
When reading from /dev/random, block at most once in cprng_strong. We are not obligated to return exactly as many bytes as requested, and many applications -- notably those that use stdio or otherwise buffered I/O to read from /dev/random -- try to read many more than 32 bytes at a time from /dev/random even if all they are about to use is 32 bytes. In this case, blocking until we have enough entropy to fill a large buffer causes needless application delays, e.g. causing cgdconfig (which reads from /dev/random with stdio) to hang at boot when trying to configure a random-keyed device for swap. Patch tested by Aran Clauson. Fixes PR kern/48028.
Initialize some variables to make the vax build happy. XXX Not sure why this problem only showed up on vax builds.
Fix races in /dev/u?random initialization and accounting. - Push /dev/random `information-theoretic' accounting into cprng(9). - Use percpu(9) for the per-CPU CPRNGs. - Use atomics with correct memory barriers for lazy CPRNG creation. - Remove /dev/random file kmem grovelling from fstat(1).
resync from head
Rework rndsink(9) abstraction and adapt arc4random(9) and cprng(9). rndsink(9): - Simplify API. - Simplify locking scheme. - Add a man page. - Avoid races in destruction. - Avoid races in requesting entropy now and scheduling entropy later. Periodic distribution of entropy to sinks reduces the need for the last one, but this way we don't need to rely on periodic distribution (e.g., in a future tickless NetBSD). rndsinks_lock should probably eventually merge with the rndpool lock, but we'll put that off for now. cprng(9): - Make struct cprng_strong opaque. - Move rndpseudo.c parts that futz with cprng guts to subr_cprng.c. - Fix kevent locking. (Is kevent locking documented anywhere?) - Stub out rump cprng further until we can rumpify rndsink instead. - Strip code to grovel through struct cprng_strong in fstat.
Convert the entropy pool framework from pseudo-callout-driven to soft interrupt driven operation. Add a polling mode of operation -- now we can ask hardware random number generators to top us up just when we need it (bcm2835_rng and amdpm converted as examples). Fix a stall noticed with repeated reads from /dev/random while testing.
resync with head
sync with (a bit old) head
move context struct to a header for the benefit of fstat.
sync to latest -current.
sync with head.
Pull up: revision 1.10 src/sys/dev/rndpseudo.c revision 1.9 src/sys/kern/subr_cprng.c (requested by tls in ticket 273). Fix two problems that could cause /dev/random to not wake up readers when entropy became available.
Fix two problems that could cause /dev/random to not wake up readers when entropy became available.
sync to latest -current.
Pull up following revision(s) (requested by tls in ticket #190): sys/sys/rnd.h: revision 1.31 sys/sys/rnd.h: revision 1.32 sys/sys/cprng.h: revision 1.5 sys/kern/subr_cprng.c: revision 1.8 share/man/man4/rnd.4: revision 1.19 sys/kern/kern_rndq.c: revision 1.3 sys/dev/rndpseudo.c: revision 1.8 sys/dev/rndpseudo.c: revision 1.9 sys/kern/kern_rndpool.c: revision 1.2 Address multiple problems with rnd(4)/cprng(9): 1) Add a per-cpu CPRNG to handle short reads from /dev/urandom so that programs like perl don't drain the entropy pool dry by repeatedly opening, reading 4 bytes, closing. 2) Really fix the locking around reseeds and destroys. 3) Fix the opportunistic-reseed strategy so it actually works, reseeding existing RNGs once each (as they are used, so idle RNGs don't get reseeded) until the pool is half empty or newly full again. Fix a bug and a compilation problem. Bug: spin mutexes don't have owners, so KASSERT(!mutex_owned()) shouldn't be used to assert that the current LWP does not have the mutex. Compilation problem: explicitly include sys/mutex.h from rnd.h so evbarm builds again.
Fix a bug and a compilation problem. Bug: spin mutexes don't have owners, so KASSERT(!mutex_owned()) shouldn't be used to assert that the current LWP does not have the mutex. Compilation problem: explicitly include sys/mutex.h from rnd.h so evbarm builds again.
Pull up following revision(s) (requested by tls in ticket #185): sys/kern/subr_cprng.c: revision 1.6 sys/kern/subr_cprng.c: revision 1.7 sys/lib/libkern/arc4random.c: revision 1.32 sys/kern/kern_rndq.c: revision 1.2 sys/dev/rndpseudo.c: revision 1.7 sys/sys/rnd.h: revision 1.30 Add a spin mutex to the rndsink structure; it is used to avoid lock ordering and sleep-holding-locks problems when rekeying, and thus to avoid a nasty race between cprng destruction and reseeding. Fix LOCKDEBUG problems pointed out by drochner@ 1) Lock ordering in cprng_strong_destroy had us take a spin mutex then an adaptive mutex. Can't do that. Reordering this requires changing cprng_strong_reseed to tryenter the cprng's own mutex and skip the reseed on failure, or we could deadlock. 2) Can't free memory with a valid mutex in it. reorder initialization to improve error handling in case the system runs out of file descriptors, avoids LOCKDEBUG panic due to double mutex initialization
Address multiple problems with rnd(4)/cprng(9): 1) Add a per-cpu CPRNG to handle short reads from /dev/urandom so that programs like perl don't drain the entropy pool dry by repeatedly opening, reading 4 bytes, closing. 2) Really fix the locking around reseeds and destroys. 3) Fix the opportunistic-reseed strategy so it actually works, reseeding existing RNGs once each (as they are used, so idle RNGs don't get reseeded) until the pool is half empty or newly full again.
sync with head
sync to latest -current.
file rndpseudo.c was added on branch yamt-pagecache on 2012-04-17 00:07:26 +0000
reorder initialization to improve error handling in case the system runs out of file descriptors, avoids LOCKDEBUG panic due to double mutex initialization
merge to -current.
file rndpseudo.c was added on branch jmcneill-usbmp on 2012-02-18 07:34:06 +0000
Revert previous; the #include was already present, and I got confused by a merge error.
#include "opt_compat_netbsd.h"
Add COMPAT_50 and COMPAT_NETBSD32 compatibility code for rnd(4) ioctl commands. Tested with "rndctl -ls" using an old 32-bit version of rndctl(8) (built for NetBSD-5.99.56/i386) and a new 64-bit kernel (NetBSD-5.99.59/amd64).
Return ENOTTY, not EINVAL, when the ioctl command is unrecognised.
make this build with RND_DEBUG
Separate /dev/random pseudodevice implemenation from kernel entropy pool implementation. Rewrite pseudodevice code to use cprng_strong(9). The new pseudodevice is cloning, so each caller gets bits from a stream generated with its own key. Users of /dev/urandom get their generators keyed on a "best effort" basis -- the kernel will rekey generators whenever the entropy pool hits the high water mark -- while users of /dev/random get their generators rekeyed every time key-length bits are output. The underlying cprng_strong API can use AES-256 or AES-128, but we use AES-128 because of concerns about related-key attacks on AES-256. This improves performance (and reduces entropy pool depletion) significantly for users of /dev/urandom but does cause users of /dev/random to rekey twice as often. Also fixes various bugs (including some missing locking and a reseed-counter overflow in the CTR_DRBG code) found while testing this. For long reads, this generator is approximately 20 times as fast as the old generator (dd with bs=64K yields 53MB/sec on 2Ghz Core2 instead of 2.5MB/sec) and also uses a separate mutex per instance so concurrency is greatly improved. For reads of typical key sizes for modern cryptosystems (16-32 bytes) performance is about the same as the old code: a little better for 32 bytes, a little worse for 16 bytes.