Commit Graph

26 Commits

Author SHA1 Message Date
Konstantin Belousov
48e279eaa7 Fix random.ko module.
- Remove duplicated sources between standard part of the kernel and
  module.  In particular, it caused duplicated lock initialization and
  sysctl registration, both having bad consequences.
- Add missed source files to module.
- Static part of the kernel provides randomdev module, not
  random_adaptors.  Correct dependencies.
- Use cdev modules declaration macros.

Approved by:	secteam (delphij)
Reviewed by:	markm
2014-11-07 20:23:43 +00:00
Mark Murray
10cb24248a 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)
2014-10-30 21:21:53 +00:00
John-Mark Gurney
f225bcd157 I clearly didn't test the modules... add sha256c.c to the various
modules that included sha2.c...
2014-03-16 01:55:30 +00:00
Mark Murray
7ca14acd4f Add needed files to the KLD random.ko.
Approved by:	re (kib)
2013-10-14 17:43:22 +00:00
Dag-Erling Smørgrav
db3fcaf970 Add YARROW_RNG and FORTUNA_RNG to sys/conf/options.
Add a SYSINIT that forces a reseed during proc0 setup, which happens
fairly late in the boot process.

Add a RANDOM_DEBUG option which enables some debugging printf()s.

Add a new RANDOM_ATTACH entropy source which harvests entropy from the
get_cyclecount() delta across each call to a device attach method.
2013-10-08 11:05:26 +00:00
Mark Murray
ddbfa6b19e 1) example (partially humorous random_adaptor, that I call "EXAMPLE")
* It's not meant to be used in a real system, it's there to show how
   the basics of how to create interfaces for random_adaptors. Perhaps
   it should belong in a manual page

2) Move probe.c's functionality in to random_adaptors.c
 * rename random_ident_hardware() to random_adaptor_choose()

3) Introduce a new way to choose (or select) random_adaptors via tunable
"rngs_want" It's a list of comma separated names of adaptors, ordered
by preferences. I.e.:
rngs_want="yarrow,rdrand"

Such setting would cause yarrow to be preferred to rdrand. If neither of
them are available (or registered), then system will default to
something reasonable (currently yarrow). If yarrow is not present, then
we fall back to the adaptor that's first on the list of registered
adaptors.

4) Introduce a way where RNGs can play a role of entropy source. This is
mostly useful for HW rngs.

The way I envision this is that every HW RNG will use this
functionality by default. Functionality to disable this is also present.
I have an example of how to use this in random_adaptor_example.c (see
modload event, and init function)

5) fix kern.random.adaptors from
kern.random.adaptors: yarrowpanicblock
to
kern.random.adaptors: yarrow,panic,block

6) add kern.random.active_adaptor to indicate currently selected
adaptor:
root@freebsd04:~ # sysctl kern.random.active_adaptor
kern.random.active_adaptor: yarrow

Submitted by:	Arthur Mesh <arthurmesh@gmail.com>
2013-08-24 13:54:56 +00:00
Konstantin Belousov
6c6ff43fbe The random_adapters.c is standard in the conf/files. Revert wrong
r254185.

Pointed out by:	peter
2013-08-10 19:38:29 +00:00
Konstantin Belousov
e5e4e178b7 Restore the ability to kldload random.ko, by linking in the newly
added random_adaptors.c.
2013-08-10 18:23:28 +00:00
David E. O'Brien
0e6a0799a9 Back out r253779 & r253786. 2013-07-31 17:21:18 +00:00
David E. O'Brien
99ff83da74 Decouple yarrow from random(4) device.
* Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option.
  The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow.

* random(4) device doesn't really depend on rijndael-*.  Yarrow, however, does.

* Add random_adaptors.[ch] which is basically a store of random_adaptor's.
  random_adaptor is basically an adapter that plugs in to random(4).
  random_adaptor can only be plugged in to random(4) very early in bootup.
  Unplugging random_adaptor from random(4) is not supported, and is probably a
  bad idea anyway, due to potential loss of entropy pools.
  We currently have 3 random_adaptors:
  + yarrow
  + rdrand (ivy.c)
  + nehemeiah

* Remove platform dependent logic from probe.c, and move it into
  corresponding registration routines of each random_adaptor provider.
  probe.c doesn't do anything other than picking a specific random_adaptor
  from a list of registered ones.

* If the kernel doesn't have any random_adaptor adapters present then the
  creation of /dev/random is postponed until next random_adaptor is kldload'ed.

* Fix randomdev_soft.c to refer to its own random_adaptor, instead of a
  system wide one.

Submitted by: arthurmesh@gmail.com, obrien
Obtained from: Juniper Networks
Reviewed by: obrien
2013-07-29 20:26:27 +00:00
Konstantin Belousov
ef9461ba0e Add support for new Intel on-CPU Bull Mountain random number
generator, found on IvyBridge and supposedly later CPUs, accessible
with RDRAND instruction.

From the Intel whitepapers and articles about Bull Mountain, it seems
that we do not need to perform post-processing of RDRAND results, like
AES-encryption of the data with random IV and keys, which was done for
Padlock. Intel claims that sanitization is performed in hardware.

Make both Padlock and Bull Mountain random generators support code
covered by kernel config options, for the benefit of people who prefer
minimal kernels. Also add the tunables to disable hardware generator
even if detected.

Reviewed by:	markm, secteam (simon)
Tested by:	bapt, Michael Moll <kvedulv@kvedulv.de>
MFC after:	3 weeks
2012-09-05 13:18:51 +00:00
Jung-uk Kim
ee5f87f458 Enable hardware RNG for VIA Nano processors.
PR:		kern/163974
2012-01-09 23:20:30 +00:00
Marcel Moolenaar
4880b26184 Include nehemiah.c only on i386, as is done for the non-modules
build.
2004-04-11 15:40:18 +00:00
Mark Murray
e7806b4c0e 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!
2004-04-09 15:47:10 +00:00
Mark Murray
bbf09ad887 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.
2002-07-15 13:58:35 +00:00
Ruslan Ermilov
17d6c63672 Drop <bsd.man.mk> support from <bsd.kmod.mk>.
Not objected to by:	-current
2002-01-11 15:49:02 +00:00
Mark Murray
add3f7f3df The /dev/random driver used Rijndael, not Blowfish, now. 2001-03-10 12:57:08 +00:00
Mark Murray
c202cd74f8 Clean up Makefile, and remove the last vestiges of NOBLOCKRANDOM. 2001-01-15 19:35:00 +00:00
David E. O'Brien
c68159a6d8 Use a consistent style and one much closer to the rest of /usr/src 2001-01-06 14:00:42 +00:00
Mark Murray
5f7f65f124 Default the /dev/random loadable module to blocking-on-bootup,
but leave a commented-out macro to change this.
2000-12-02 18:29:18 +00:00
Mark Murray
5f3431b5ad As the blocking model has seems to be troublesome for many, disable
it for now with an option.

This option is already deprecated, and will be removed when the
entropy-harvesting code is fast enough to warrant it.
2000-10-27 06:06:04 +00:00
Mark Murray
a6278a2a42 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.
2000-10-14 10:59:56 +00:00
Mark Murray
4d87a031c0 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.
2000-09-10 13:52:19 +00:00
Mark Murray
c9ec235ca1 Add entropy gathering code. This will work whether the module is
compiled in or loaded.
2000-07-07 09:03:59 +00:00
Mark Murray
d040e2d053 Better style(9) for the module build. 2000-06-26 12:18:09 +00:00
Mark Murray
dc47848738 Build the entropy device (/dev/random) as a module. This may not
be a permanent rule, because this device may eventually be deemed
"effectively compulsory", and built by default directly into the
kernel. For the moment, however, this is useful for debugging and
development.

Reviewed by:	dfr
2000-06-25 10:12:33 +00:00