| History log of /src/sys/kern/subr_cprng.c |
| Revision | | Date | Author | Comments |
| 1.44 |
| 05-Aug-2023 |
riastradh | cprng(9): Drop and retake percpu reference across entropy_extract.
entropy_extract may sleep on an adaptive lock, which invalidates
percpu(9) references.
Add a note in the comment over entropy_extract about this.
Discovered by stumbling upon this panic during a test run:
[ 1.0200050] panic: kernel diagnostic assertion "(cprng == percpu_getref(cprng_fast_percpu)) && (percpu_putref(cprng_fast_percpu), true)" failed: file "/home/riastradh/netbsd/current/src/sys/rump/librump/rumpkern/../../../crypto/cprng_fast/cprng_fast.c", line 117
XXX pullup-10
|
| 1.43 |
| 13-May-2022 |
riastradh | branches: 1.43.4;
cprng(9): Fix accidental 4x seed size.
With SHA-256, NIST Hash_DRBG takes an preferred 440-bit/55-byte seed.
It's a weird number, and I'm not sure where it comes from (a quick
skim of SP800-90A doesn't turn anything up), but it's certainly
sufficient (256-bit/32-byte seed is almost certainly enough) so it's
not a problem to use something larger; Hash_DRBG can absorb seeds of
arbitrary lengths and larger seeds can't really hurt security (with
minor caveats like HMAC RO quirks that don't apply here).
Except -- owing to a typo, we actually used a 1760-bit/220-byte seed,
because I wrote `uint32_t seed[...]' instead of `uint8_t seed[...]'.
Again: not a problem to use a seed larger than needed. But let's
draw no more than we need out of the entropy pool!
Verified with CTASSERT(sizeof(seed) == 55). (Assertion omitted from
this commit because we might swap out Hash_DRBG for something else
with a different seed size like 32 bytes.)
|
| 1.42 |
| 16-Mar-2022 |
riastradh | cprng(9): Forbid use in hard interrupt context.
May need access to the global entropy pool (infrequently). This way
the global entropy pool lock can be lowered to IPL_SOFTSERIAL too,
with a little additional work.
|
| 1.41 |
| 21-Jul-2021 |
skrll | need <sys/param.h> for COHERENCY_UNIT
Minor KNF along the way.
|
| 1.40 |
| 11-May-2020 |
riastradh | branches: 1.40.6;
Remove cprng initialization order hack.
cprng_init now runs early enough that the hack should no longer be
needed to address PR port-arm32/55252.
|
| 1.39 |
| 11-May-2020 |
riastradh | Move cprng_init before configure.
This makes it available to device drivers, e.g. to generate MAC
addresses at random, without initialization order hacks.
Requires a minor initialization hack for cpu_name(primary cpu) early
on, since that doesn't get set until mi_cpu_attach which may not run
until the middle of configure. But this hack is less bad than other
initialization order hacks.
|
| 1.38 |
| 11-May-2020 |
riastradh | Work around early calls to cprng_strong.
The bottleneck here is getting percpu_create to work early enough.
We should really fix that, but for now, this workaround will serve.
Should fix PR port-arm32/55252.
|
| 1.37 |
| 30-Apr-2020 |
nia | Make kern.arandom truncate the output instead of failing with ETOOBIG
when the requested data exceeds 256 bytes in size. The actual size of
the returned data is output to oldlenp.
This matches FreeBSD's behaviour and seems to be more in line with
what software in the wild expects.
"sounds reasonble" - Riastradh
|
| 1.36 |
| 30-Apr-2020 |
riastradh | 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.
|
| 1.35 |
| 12-Apr-2020 |
maxv | Don't inline cprng_strong{32,64}(), so they can be called from asm.
|
| 1.34 |
| 04-Dec-2019 |
riastradh | branches: 1.34.6;
Disable rngtest on output of cprng_strong.
We already do a self-test for correctenss of Hash_DRBG output;
applying rngtest to it does nothing but give everyone warning fatigue
about spurious rngtest failures.
|
| 1.33 |
| 25-Nov-2019 |
riastradh | Use cprng_strong, not cprng_fast, for sysctl kern.arnd.
|
| 1.32 |
| 17-Nov-2019 |
nia | Update comment to reflect third-party software's usage of KERN_ARND.
Changing it as the comment suggests would be a very terrible idea due to
the common usage of this variable.
Returning only 32 or 64 bits also seems to be the purpose of KERN_URND,
so that functionality is already present.
|
| 1.31 |
| 02-Sep-2019 |
riastradh | 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
|
| 1.30 |
| 10-Jul-2019 |
maxv | branches: 1.30.2;
Zero out 'cprng->cs_name' entirely. Otherwise the RND pool gets polluted
by uninitialized bits from the end of the string.
|
| 1.29 |
| 01-Dec-2017 |
christos | branches: 1.29.4;
Allow attaching for write, but return no events.
|
| 1.28 |
| 25-Oct-2017 |
maya | Use C99 initializer for filterops
Mostly done with spatch with touchups for indentation
@@
expression a;
identifier b,c,d;
identifier p;
@@
const struct filterops p =
- { a, b, c, d
+ {
+ .f_isfd = a,
+ .f_attach = b,
+ .f_detach = c,
+ .f_event = d,
};
|
| 1.27 |
| 13-Apr-2015 |
riastradh | branches: 1.27.10;
More rnd.h user cleanup.
|
| 1.26 |
| 19-Nov-2014 |
christos | branches: 1.26.2;
Change debug to diagnostic so that more people see the lossage with bad
random streams, so we can debug it.
|
| 1.25 |
| 14-Aug-2014 |
riastradh | Lock cprng->cs_lock around rndsink_request to avoid race with callback.
|
| 1.24 |
| 10-Aug-2014 |
tls | branches: 1.24.2;
Merge tls-earlyentropy branch into HEAD.
|
| 1.23 |
| 17-Jan-2014 |
pooka | branches: 1.23.2;
Put cprng sysctls into subr_cprng.c. Also, make sysctl_prng static
in subr_cprng and get rid of SYSCTL_PRIVATE namespace leak macro.
Fixes ping(8) when run against a standalone rump kernel due to appearance
of the kern.urandom sysctl node (in case someone was wondering ...)
|
| 1.22 |
| 27-Jul-2013 |
skrll | Fix KASSERT to avoid assumptions about ipl order.
XXX Temporary measure?
|
| 1.21 |
| 01-Jul-2013 |
riastradh | 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).
|
| 1.20 |
| 24-Jun-2013 |
riastradh | branches: 1.20.2;
Replace consttime_bcmp/explicit_bzero by consttime_memequal/explicit_memset.
consttime_memequal is the same as the old consttime_bcmp.
explicit_memset is to memset as explicit_bzero was to bcmp.
Passes amd64 release and i386/ALL, but I'm sure I missed some spots,
so please let me know.
|
| 1.19 |
| 24-Jun-2013 |
riastradh | Include <sys/lwp.h> for curlwp.
|
| 1.18 |
| 23-Jun-2013 |
riastradh | 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.
|
| 1.17 |
| 13-Jun-2013 |
tls | 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.
|
| 1.16 |
| 28-Mar-2013 |
tls | Re-fix 'fix' for SA-2013-003. Because the original fix evaluated a flag
backwards, in low-entropy conditions there was a time interval in which
/dev/urandom could still output bits on an unacceptably short key. Output
from /dev/random was *NOT* impacted.
Eliminate the flag in question -- it's safest to always fill the requested
key buffer with output from the entropy-pool, even if we let the caller
know we couldn't provide bytes with the full entropy it requested.
Advisory will be updated soon with a full worst-case analysis of the
/dev/urandom output path in the presence of either variant of the
SA-2013-003 bug. Fortunately, because a large amount of other input
is mixed in before users can obtain any output, it doesn't look as dangerous
in practice as I'd feared it might be.
|
| 1.15 |
| 26-Jan-2013 |
tls | Fix a security issue: when we are reseeding a PRNG seeded early in boot
before we had ever had any entropy, if something else has consumed the
entropy that triggered the immediate reseed, we can reseed with as little
as sizeof(int) bytes of entropy.
|
| 1.14 |
| 20-Nov-2012 |
msaitoh | Pass correct wait channel string.
|
| 1.13 |
| 27-Oct-2012 |
matt | Use kmem_intr_alloc/kmem_intr_free
|
| 1.12 |
| 08-Sep-2012 |
msaitoh | branches: 1.12.2;
Fix a bug that kmem_alloc() is called from the interrupt context.
|
| 1.11 |
| 07-Sep-2012 |
tls | Fix kern/46911: note that we rekeyed the cprng so we don't keep doing so.
|
| 1.10 |
| 05-Sep-2012 |
tls | Don't wait until the pool *fills* to rekey anything that was keyed with
insufficient entropy at boot: key it as soon as it makes any request after
we hit the minimum entropy threshold.
This too should help avoid predictable output at boot time.
|
| 1.9 |
| 19-May-2012 |
tls | Fix two problems that could cause /dev/random to not wake up readers when entropy became available.
|
| 1.8 |
| 17-Apr-2012 |
tls | 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.
|
| 1.7 |
| 10-Apr-2012 |
tls | branches: 1.7.2;
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.
|
| 1.6 |
| 10-Apr-2012 |
tls | 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.
|
| 1.5 |
| 17-Dec-2011 |
tls | branches: 1.5.2;
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.
|
| 1.4 |
| 29-Nov-2011 |
njoly | branches: 1.4.2;
One semicolon is enough.
|
| 1.3 |
| 29-Nov-2011 |
tls | Remove rnd_extract_data from the public kernel API (it is for use by the
stream generators only). Clean up some related minor issues.
|
| 1.2 |
| 21-Nov-2011 |
tsutsui | Include MD <machine/cpu_counter.h> only if defined(__HAVE_CPU_COUNTER).
XXX: Why not timecounter(9) but deprecated cpu_counter32() and microtime(9)?
|
| 1.1 |
| 19-Nov-2011 |
tls | First step of random number subsystem rework described in
<20111022023242.BA26F14A158@mail.netbsd.org>. This change includes
the following:
An initial cleanup and minor reorganization of the entropy pool
code in sys/dev/rnd.c and sys/dev/rndpool.c. Several bugs are
fixed. Some effort is made to accumulate entropy more quickly at
boot time.
A generic interface, "rndsink", is added, for stream generators to
request that they be re-keyed with good quality entropy from the pool
as soon as it is available.
The arc4random()/arc4randbytes() implementation in libkern is
adjusted to use the rndsink interface for rekeying, which helps
address the problem of low-quality keys at boot time.
An implementation of the FIPS 140-2 statistical tests for random
number generator quality is provided (libkern/rngtest.c). This
is based on Greg Rose's implementation from Qualcomm.
A new random stream generator, nist_ctr_drbg, is provided. It is
based on an implementation of the NIST SP800-90 CTR_DRBG by
Henric Jungheim. This generator users AES in a modified counter
mode to generate a backtracking-resistant random stream.
An abstraction layer, "cprng", is provided for in-kernel consumers
of randomness. The arc4random/arc4randbytes API is deprecated for
in-kernel use. It is replaced by "cprng_strong". The current
cprng_fast implementation wraps the existing arc4random
implementation. The current cprng_strong implementation wraps the
new CTR_DRBG implementation. Both interfaces are rekeyed from
the entropy pool automatically at intervals justifiable from best
current cryptographic practice.
In some quick tests, cprng_fast() is about the same speed as
the old arc4randbytes(), and cprng_strong() is about 20% faster
than rnd_extract_data(). Performance is expected to improve.
The AES code in src/crypto/rijndael is no longer an optional
kernel component, as it is required by cprng_strong, which is
not an optional kernel component.
The entropy pool output is subjected to the rngtest tests at
startup time; if it fails, the system will reboot. There is
approximately a 3/10000 chance of a false positive from these
tests. Entropy pool _input_ from hardware random numbers is
subjected to the rngtest tests at attach time, as well as the
FIPS continuous-output test, to detect bad or stuck hardware
RNGs; if any are detected, they are detached, but the system
continues to run.
A problem with rndctl(8) is fixed -- datastructures with
pointers in arrays are no longer passed to userspace (this
was not a security problem, but rather a major issue for
compat32). A new kernel will require a new rndctl.
The sysctl kern.arandom() and kern.urandom() nodes are hooked
up to the new generators, but the /dev/*random pseudodevices
are not, yet.
Manual pages for the new kernel interfaces are forthcoming.
|
| 1.4.2.3 |
| 02-Jun-2012 |
mrg | sync to latest -current.
|
| 1.4.2.2 |
| 29-Apr-2012 |
mrg | sync to latest -current.
|
| 1.4.2.1 |
| 18-Feb-2012 |
mrg | merge to -current.
|
| 1.5.2.9 |
| 03-Mar-2018 |
snj | Apply patch (requested by riastradh in ticket #1512):
Fix panic when waiting with kqueue/kevent for a read from
/dev/random.
|
| 1.5.2.8 |
| 29-Mar-2013 |
msaitoh | branches: 1.5.2.8.2;
Pull up following revision(s) (requested by tls in ticket #859):
sys/kern/subr_cprng.c: revision 1.16
Re-fix 'fix' for SA-2013-003. Because the original fix evaluated a flag
backwards, in low-entropy conditions there was a time interval in which
/dev/urandom could still output bits on an unacceptably short key. Output
from /dev/random was *NOT* impacted.
Eliminate the flag in question -- it's safest to always fill the requested
key buffer with output from the entropy-pool, even if we let the caller
know we couldn't provide bytes with the full entropy it requested.
Advisory will be updated soon with a full worst-case analysis of the
/dev/urandom output path in the presence of either variant of the
SA-2013-003 bug. Fortunately, because a large amount of other input
is mixed in before users can obtain any output, it doesn't look as dangerous
in practice as I'd feared it might be.
|
| 1.5.2.7 |
| 26-Jan-2013 |
bouyer | Pull up following revision(s) (requested by tls in ticket #800):
sys/kern/subr_cprng.c: revision 1.15
Fix a security issue: when we are reseeding a PRNG seeded early in boot
before we had ever had any entropy, if something else has consumed the
entropy that triggered the immediate reseed, we can reseed with as little
as sizeof(int) bytes of entropy.
|
| 1.5.2.6 |
| 24-Nov-2012 |
jdc | Pull up revision 1.14 (requested by msaitoh in ticket #714).
Pass correct wait channel string.
|
| 1.5.2.5 |
| 31-Oct-2012 |
riz | Pull up following revision(s) (requested by msaitoh in ticket #644):
sys/netinet/tcp_subr.c: revision 1.248
sys/kern/subr_cprng.c: revision 1.12
Fix a bug that kmem_alloc() is called from the interrupt context.
|
| 1.5.2.4 |
| 17-Oct-2012 |
riz | Pull up following revision(s) (requested by tls in ticket #558):
sys/sys/rnd.h: revision 1.33
sys/kern/subr_cprng.c: revision 1.10
sys/kern/kern_rndq.c: revision 1.4
sys/kern/subr_cprng.c: revision 1.11
sys/kern/kern_rndq.c: revision 1.5
Try to help embedded systems a _little_ bit: stir in the system boot time
as early as possible. On systems with no cycle counter (or very very
predictable cycle counts early in boot) at least this will cause some
difference across boots.
Don't wait until the pool *fills* to rekey anything that was keyed with
insufficient entropy at boot: key it as soon as it makes any request after
we hit the minimum entropy threshold.
This too should help avoid predictable output at boot time.
Fix kern/46911: note that we rekeyed the cprng so we don't keep doing so.
|
| 1.5.2.3 |
| 21-May-2012 |
jdc | branches: 1.5.2.3.4;
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.
|
| 1.5.2.2 |
| 20-Apr-2012 |
riz | 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.
|
| 1.5.2.1 |
| 19-Apr-2012 |
riz | 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
|
| 1.5.2.8.2.1 |
| 03-Mar-2018 |
snj | Apply patch (requested by riastradh in ticket #1512):
Fix panic when waiting with kqueue/kevent for a read from
/dev/random.
|
| 1.5.2.3.4.3 |
| 03-Mar-2018 |
snj | Apply patch (requested by riastradh in ticket #1512):
Fix panic when waiting with kqueue/kevent for a read from
/dev/random.
|
| 1.5.2.3.4.2 |
| 29-Mar-2013 |
msaitoh | Pull up following revision(s) (requested by tls in ticket #859):
sys/kern/subr_cprng.c: revision 1.16
Re-fix 'fix' for SA-2013-003. Because the original fix evaluated a flag
backwards, in low-entropy conditions there was a time interval in which
/dev/urandom could still output bits on an unacceptably short key. Output
from /dev/random was *NOT* impacted.
Eliminate the flag in question -- it's safest to always fill the requested
key buffer with output from the entropy-pool, even if we let the caller
know we couldn't provide bytes with the full entropy it requested.
Advisory will be updated soon with a full worst-case analysis of the
/dev/urandom output path in the presence of either variant of the
SA-2013-003 bug. Fortunately, because a large amount of other input
is mixed in before users can obtain any output, it doesn't look as dangerous
in practice as I'd feared it might be.
|
| 1.5.2.3.4.1 |
| 26-Jan-2013 |
bouyer | Pull up following revision(s) (requested by tls in ticket #800):
sys/kern/subr_cprng.c: revision 1.15
Fix a security issue: when we are reseeding a PRNG seeded early in boot
before we had ever had any entropy, if something else has consumed the
entropy that triggered the immediate reseed, we can reseed with as little
as sizeof(int) bytes of entropy.
|
| 1.7.2.6 |
| 22-May-2014 |
yamt | 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")
|
| 1.7.2.5 |
| 16-Jan-2013 |
yamt | sync with (a bit old) head
|
| 1.7.2.4 |
| 30-Oct-2012 |
yamt | sync with head
|
| 1.7.2.3 |
| 23-May-2012 |
yamt | sync with head.
|
| 1.7.2.2 |
| 17-Apr-2012 |
yamt | sync with head
|
| 1.7.2.1 |
| 10-Apr-2012 |
yamt | file subr_cprng.c was added on branch yamt-pagecache on 2012-04-17 00:08:27 +0000
|
| 1.12.2.5 |
| 03-Dec-2017 |
jdolecek | update from HEAD
|
| 1.12.2.4 |
| 20-Aug-2014 |
tls | Rebase to HEAD as of a few days ago.
|
| 1.12.2.3 |
| 23-Jun-2013 |
tls | resync from head
|
| 1.12.2.2 |
| 25-Feb-2013 |
tls | resync with head
|
| 1.12.2.1 |
| 20-Nov-2012 |
tls | Resync to 2012-11-19 00:00:00 UTC
|
| 1.20.2.2 |
| 18-May-2014 |
rmind | sync with head
|
| 1.20.2.1 |
| 28-Aug-2013 |
rmind | sync with head
|
| 1.23.2.2 |
| 09-Aug-2014 |
tls | Replace "ccrand" ChaCha implementation of cprng_fast with Taylor's smaller
and somewhat simpler one. Fix rump builds so we can build a distribution.
|
| 1.23.2.1 |
| 17-Jul-2014 |
tls | 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.
|
| 1.24.2.3 |
| 25-Nov-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1714):
sys/kern/subr_cprng.c: revision 1.33
Use cprng_strong, not cprng_fast, for sysctl kern.arnd.
|
| 1.24.2.2 |
| 03-Sep-2019 |
martin | 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...
|
| 1.24.2.1 |
| 15-Aug-2014 |
martin | branches: 1.24.2.1.2; 1.24.2.1.6;
Pull up following revision(s) (requested by riastradh in ticket #22):
sys/kern/subr_cprng.c: revision 1.25
Lock cprng->cs_lock around rndsink_request to avoid race with callback.
|
| 1.24.2.1.6.2 |
| 25-Nov-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1714):
sys/kern/subr_cprng.c: revision 1.33
Use cprng_strong, not cprng_fast, for sysctl kern.arnd.
|
| 1.24.2.1.6.1 |
| 03-Sep-2019 |
martin | 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...
|
| 1.24.2.1.2.2 |
| 25-Nov-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1714):
sys/kern/subr_cprng.c: revision 1.33
Use cprng_strong, not cprng_fast, for sysctl kern.arnd.
|
| 1.24.2.1.2.1 |
| 03-Sep-2019 |
martin | 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...
|
| 1.26.2.1 |
| 06-Jun-2015 |
skrll | Sync with HEAD
|
| 1.27.10.3 |
| 30-Apr-2020 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1543):
sys/kern/subr_cprng.c: revision 1.34
Disable rngtest on output of cprng_strong.
We already do a self-test for correctenss of Hash_DRBG output;
applying rngtest to it does nothing but give everyone warning fatigue
about spurious rngtest failures.
|
| 1.27.10.2 |
| 25-Nov-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #1459):
sys/kern/subr_cprng.c: revision 1.33
Use cprng_strong, not cprng_fast, for sysctl kern.arnd.
|
| 1.27.10.1 |
| 03-Sep-2019 |
martin | 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...
|
| 1.29.4.2 |
| 21-Apr-2020 |
martin | Sync with HEAD
|
| 1.29.4.1 |
| 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
| 1.30.2.4 |
| 18-May-2020 |
martin | Pull up following revision(s) (requested by nia in ticket #914):
sys/kern/subr_cprng.c: revision 1.37 (via patch, adapted)
Make kern.arandom truncate the output instead of failing with ETOOBIG
when the requested data exceeds 256 bytes in size. The actual size of
the returned data is output to oldlenp.
This matches FreeBSD's behaviour and seems to be more in line with
what software in the wild expects.
"sounds reasonble" - Riastradh
|
| 1.30.2.3 |
| 30-Apr-2020 |
martin | Pull up following revision(s) (requested by riastradh in ticket #874):
sys/kern/subr_cprng.c: revision 1.34
Disable rngtest on output of cprng_strong.
We already do a self-test for correctenss of Hash_DRBG output;
applying rngtest to it does nothing but give everyone warning fatigue
about spurious rngtest failures.
|
| 1.30.2.2 |
| 25-Nov-2019 |
martin | Pull up following revision(s) (requested by riastradh in ticket #481):
sys/kern/subr_cprng.c: revision 1.33
Use cprng_strong, not cprng_fast, for sysctl kern.arnd.
|
| 1.30.2.1 |
| 03-Sep-2019 |
martin | 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
|
| 1.34.6.1 |
| 20-Apr-2020 |
bouyer | Sync with HEAD
|
| 1.40.6.1 |
| 01-Aug-2021 |
thorpej | Sync with HEAD.
|
| 1.43.4.1 |
| 11-Aug-2023 |
martin | Pull up following revision(s) (requested by riastradh in ticket #319):
sys/dev/pci/ubsec.c: revision 1.64
sys/dev/pci/hifn7751.c: revision 1.82
lib/libc/gen/getentropy.3: revision 1.5
lib/libc/gen/getentropy.3: revision 1.6
share/man/man4/rnd.4: revision 1.41
lib/libc/sys/getrandom.2: revision 1.2
lib/libc/sys/getrandom.2: revision 1.3
share/man/man5/rc.conf.5: revision 1.193
share/man/man7/entropy.7: revision 1.5
share/man/man7/entropy.7: revision 1.6
share/man/man7/entropy.7: revision 1.7
share/man/man7/entropy.7: revision 1.8
etc/security: revision 1.130
share/man/man7/entropy.7: revision 1.9
etc/security: revision 1.131
sys/crypto/cprng_fast/cprng_fast.c: revision 1.19
sys/sys/rndio.h: revision 1.3
tests/lib/libc/sys/t_getrandom.c: revision 1.5
etc/defaults/rc.conf: revision 1.164
etc/defaults/rc.conf: revision 1.165
sys/sys/rndsource.h: revision 1.10
sys/kern/kern_entropy.c: revision 1.62
sys/kern/kern_entropy.c: revision 1.63
sys/kern/kern_entropy.c: revision 1.64
sys/kern/subr_cprng.c: revision 1.44
sys/kern/kern_entropy.c: revision 1.65
sys/kern/kern_clock.c: revision 1.149
sys/dev/pci/viornd.c: revision 1.22
share/man/man9/rnd.9: revision 1.32
sys/kern/subr_prf.c: revision 1.202
sys/sys/rndsource.h: revision 1.8
sys/sys/rndsource.h: revision 1.9
share/man/man7/entropy.7: revision 1.10
1. Reinstate netbsd<=9 entropy estimator to unblock /dev/random, in
parallel with assessment of only confident entropy sources (seed,
HWRNG) for security warnings like sshd keys in motd and daily
insecurity report.
2. Make multiuser boot wait for first /dev/random output soon after
loading a seed and configuring rndctl, so that getentropy(3) meets
its contract starting early at boot without introducing blocking
paths that could cause hangs in init(8) or single-user mode.
Operators can choose to disable this wait in rc.conf.
3. Fix some bugs left over from reducing the global entropy lock from
a spin lock at IPL_VM to an adaptive lock at IPL_SOFTSERIAL.
4. Update man pages.
|
