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.
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.
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!).
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.
- 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).
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.
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.
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.
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.
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).
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.
