Commit Graph

24 Commits

Author SHA1 Message Date
Mateusz Guzik
5e57adc874 random(4): depessimize arc4random
- __predict_false reseeding on entry as it is almost never true.
- don't blindly atomic_cmpset as on x86 it ends up dirtying the cacheline.
it almost ever succeeds per above
- fetch the timestamp prior to getting the cpu number

Reviewed by:	cem
Approved by:	secteam (delphij)
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D20242
2019-05-12 06:32:46 +00:00
Conrad Meyer
3782136ff1 random(4): Restore availability tradeoff prior to r346250
As discussed in that commit message, it is a dangerous default.  But the
safe default causes enough pain on a variety of platforms that for now,
restore the prior default.

Some of this is self-induced pain we should/could do better about; for
example, programmatic CI systems and VM managers should introduce entropy
from the host for individual VM instances.  This is considered a future work
item.

On modern x86 and Power9 systems, this may be wholly unnecessary after
D19928 lands (even in the non-ideal case where early /boot/entropy is
unavailable), because they have fast hardware random sources available early
in boot.  But D19928 is not yet landed and we have a host of architectures
which do not provide fast random sources.

This change adds several tunables and diagnostic sysctls, documented
thoroughly in UPDATING and sys/dev/random/random_infra.c.

PR:		230875 (reopens)
Reported by:	adrian, jhb, imp, and probably others
Reviewed by:	delphij, imp (earlier version), markm (earlier version)
Discussed with:	adrian
Approved by:	secteam(delphij)
Relnotes:	yeah
Security:	related
Differential Revision:	https://reviews.freebsd.org/D19944
2019-04-18 20:48:54 +00:00
Conrad Meyer
13774e8228 random(4): Block read_random(9) on initial seeding
read_random() is/was used, mostly without error checking, in a lot of
very sensitive places in the kernel -- including seeding the widely used
arc4random(9).

Most uses, especially arc4random(9), should block until the device is seeded
rather than proceeding with a bogus or empty seed.  I did not spy any
obvious kernel consumers where blocking would be inappropriate (in the
sense that lack of entropy would be ok -- I did not investigate locking
angle thoroughly).  In many instances, arc4random_buf(9) or that family
of APIs would be more appropriate anyway; that work was done in r345865.

A minor cleanup was made to the implementation of the READ_RANDOM function:
instead of using a variable-length array on the stack to temporarily store
all full random blocks sufficient to satisfy the requested 'len', only store
a single block on the stack.  This has some benefit in terms of reducing
stack usage, reducing memcpy overhead and reducing devrandom output leakage
via the stack.  Additionally, the stack block is now safely zeroed if it was
used.

One caveat of this change is that the kern.arandom sysctl no longer returns
zero bytes immediately if the random device is not seeded.  This means that
FreeBSD-specific userspace applications which attempted to handle an
unseeded random device may be broken by this change.  If such behavior is
needed, it can be replaced by the more portable getrandom(2) GRND_NONBLOCK
option.

On any typical FreeBSD system, entropy is persisted on read/write media and
used to seed the random device very early in boot, and blocking is never a
problem.

This change primarily impacts the behavior of /dev/random on embedded
systems with read-only media that do not configure "nodevice random".  We
toggle the default from 'charge on blindly with no entropy' to 'block
indefinitely.'  This default is safer, but may cause frustration.  Embedded
system designers using FreeBSD have several options.  The most obvious is to
plan to have a small writable NVRAM or NAND to persist entropy, like larger
systems.  Early entropy can be fed from any loader, or by writing directly
to /dev/random during boot.  Some embedded SoCs now provide a fast hardware
entropy source; this would also work for quickly seeding Fortuna.  A 3rd
option would be creating an embedded-specific, more simplistic random
module, like that designed by DJB in [1] (this design still requires a small
rewritable media for forward secrecy).  Finally, the least preferred option
might be "nodevice random", although I plan to remove this in a subsequent
revision.

To help developers emulate the behavior of these embedded systems on
ordinary workstations, the tunable kern.random.block_seeded_status was
added.  When set to 1, it blocks the random device.

I attempted to document this change in random.4 and random.9 and ran into a
bunch of out-of-date or irrelevant or inaccurate content and ended up
rototilling those documents more than I intended to.  Sorry.  I think
they're in a better state now.

PR:		230875
Reviewed by:	delphij, markm (earlier version)
Approved by:	secteam(delphij), devrandom(markm)
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D19744
2019-04-15 18:40:36 +00:00
Mark Murray
150890b0c6 Replace the RC4 algorithm for generating in-kernel secure random
numbers with Chacha20. Keep the API, though, as that is what the
other *BSD's have done.

Use the boot-time entropy stash (if present) to bootstrap the
in-kernel entropy source.

Reviewed by: delphij,rwatson
Approved by: so(delphij)
MFC after: 2 months
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D10048
2017-04-16 09:11:02 +00:00
Xin LI
91868665a9 Discard first 3072 bytes of RC4 keystream, this is a bandaid
that allows us to work on switching to a more modern PRNG.

Submitted by:	Steven Chamberlain <steven pyro eu org>
Approved by:	so
2017-03-14 06:00:44 +00:00
Fabien Thomas
cdaf963483 Update r309143 to prevent false sharing.
Reported by:	mjg
Approved by:	so
MFC after:	1 month
2016-11-25 17:20:23 +00:00
Fabien Thomas
dcf3302859 In a dual processor system (2*6 cores) during IPSec throughput tests,
we see a lot of contention on the arc4 lock, used to generate the IV
of the ESP output packets.

The idea of this patch is to split this mutex in order to reduce the
contention on this lock.

Reviewed by:	delphij, markm, ache
Approved by:	so
Obtained from: emeric.poupon@stormshield.eu
MFC after: 1 month
Sponsored by:	Stormshield
Differential Revision:	https://reviews.freebsd.org/D8130
2016-11-25 13:49:33 +00:00
Mark Murray
d1b06863fb 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)
2015-06-30 17:00:45 +00:00
Andrey A. Chernov
2b50ce65be Attempt to mitigate poor initialization of arc4 by one-shot
reinitialization from yarrow right after good entropy is harvested.

Approved by:    secteam (delphij)
MFC after:      1 week
2013-04-19 00:30:52 +00:00
Andrey A. Chernov
b834665cd5 Return arc4_i = arc4_j = 0; line from previous backing out since
just found it in OpenBSD, see their sys/crypto/arc4.c, function
rc4_keysetup, line ctx->x = ctx->y = 0;

Obtained from:  OpenBSD
2008-07-26 16:42:45 +00:00
Andrey A. Chernov
fff6495ea6 Per rwatson's request:
"If you don't get a review within a day or two, I would firmly recommend
backing out the changes"

back out all my changes as unreviewed by secteam@ yet.
2008-07-25 15:53:32 +00:00
Andrey A. Chernov
d16863efa6 1) Initialize arc4_i and arc4_j to 0 after key mixing as recommended in
draft-kaukonen-cipher-arcfour-03.txt (3.1.5)

2) Drop first 768 bytes as standard RC4-drop(768)
2008-07-22 16:16:51 +00:00
Mike Silbersack
2f823fa326 Lock down arc4random so it can be safely called w/o Giant.
Minor code reorganization was required, but the only functional
change was that the first 1024 bytes of output are thrown out
after each reseed, rather than just the initial seed.
2003-08-15 06:34:47 +00:00
David E. O'Brien
ab0de15baf Use __FBSDID(). 2003-06-11 05:37:42 +00:00
Poul-Henning Kamp
2c38619b52 Slight overhaul of arc4random() and friends.
One bug fixed:  Use getmicrouptime() to trigger reseeds so that we
cannot be tricked by a clock being stepped backwards.

Express parameters in natural units and with natural names.

Don't use struct timeval more than we need to.

Various stylistic and readability polishing.

Introduce arc4rand(void *ptr, u_int len, int reseed) function which
returns a stream of pseudo-random bytes, observing the automatic
reseed criteria as well as allowing forced reseeds.

Rewrite arc4random() in terms of arc4rand().

Sponsored by:   DARPA & NAI Labs.
2002-10-11 13:13:08 +00:00
Bruce Evans
60f8e3af92 Fixed some typos, verboseness and misformatting in comments. 2001-08-30 12:30:58 +00:00
Mike Silbersack
3a7810bc39 Minor improvements to arc4random():
- Decrease reseeding interval from every 64 to every 16384 runs
  to reduce entropy usage.
- Add time based reseeding.  (Every 5 minutes.)
- Throw away the first 256 words of output as suggested in
  "Weaknesses in the Key Scheduling Algorithm of RC4."

Reviewed by: Mark Murray
MFC After: jkh says ok
2001-08-30 01:15:25 +00:00
Mark Murray
4cb1e53914 Recouple arc4random(9) to the entropy device. This works whether the
entropy device is loaded or not.

If the entropy device is NOT loaded, the the quality of perturbations
supplied by this will suffer.
2000-12-02 16:23:54 +00:00
John Baldwin
e2059d0bfb Back out previous revision now that sys/random.h is properly fixed. 2000-09-11 19:34:04 +00:00
John Baldwin
ebbb6afce3 Add #include's of sys/proc.h and sys/param.h to silence a warning. 2000-09-11 05:51:58 +00:00
Mark Murray
bf3191e9fa Comment out unavailable call. This needs to be revisited when the entropy
device is complete.
Reviewed by:	dfr
2000-06-25 10:15:58 +00:00
Dan Moschuk
e6082d1936 In the extremely miniscule chance that read_random returns <= 0, don't try
and use that return code as a modulus (panics are bad, mmmkay?)
1999-11-29 19:23:35 +00:00
Dan Moschuk
d65b167028 Address the concerns of the ``randomness'' of the initial PRNG. Now, we
use bits from /dev/random to stir the S-box.  Also add an internal counter to
keep the S-box stirred on a regular basis.

Reviewed by: msmith
1999-11-28 23:39:49 +00:00
Dan Moschuk
ee3fd60126 Introduce OpenBSD-like Random PIDs. Controlled by a sysctl knob
(kern.randompid), which is currently defaulted off.  Use ARC4 (RC4) for our
random number generation, which will not get me executed for violating
crypto laws; a Good Thing(tm).

Reviewed and Approved by: bde, imp
1999-11-28 17:51:09 +00:00