70d85b1cf3
Refactor of /dev/random device. Main points include: * Userland seeding is no longer used. This auto-seeds at boot time on PC/Desktop setups; this may need some tweeking and intelligence from those folks setting up embedded boxes, but the work is believed to be minimal. * An entropy cache is written to /entropy (even during installation) and the kernel uses this at next boot. * An entropy file written to /boot/entropy can be loaded by loader(8) * Hardware sources such as rdrand are fed into Yarrow, and are no longer available raw. ------------------------------------------------------------------------ r256240 | des | 2013-10-09 21:14:16 +0100 (Wed, 09 Oct 2013) | 4 lines Add a RANDOM_RWFILE option and hide the entropy cache code behind it. Rename YARROW_RNG and FORTUNA_RNG to RANDOM_YARROW and RANDOM_FORTUNA. Add the RANDOM_* options to LINT. ------------------------------------------------------------------------ r256239 | des | 2013-10-09 21:12:59 +0100 (Wed, 09 Oct 2013) | 2 lines Define RANDOM_PURE_RNDTEST for rndtest(4). ------------------------------------------------------------------------ r256204 | des | 2013-10-09 18:51:38 +0100 (Wed, 09 Oct 2013) | 2 lines staticize struct random_hardware_source ------------------------------------------------------------------------ r256203 | markm | 2013-10-09 18:50:36 +0100 (Wed, 09 Oct 2013) | 2 lines Wrap some policy-rich code in 'if NOTYET' until we can thresh out what it really needs to do. ------------------------------------------------------------------------ r256184 | des | 2013-10-09 10:13:12 +0100 (Wed, 09 Oct 2013) | 2 lines Re-add /dev/urandom for compatibility purposes. ------------------------------------------------------------------------ r256182 | des | 2013-10-09 10:11:14 +0100 (Wed, 09 Oct 2013) | 3 lines Add missing include guards and move the existing ones out of the implementation namespace. ------------------------------------------------------------------------ r256168 | markm | 2013-10-08 23:14:07 +0100 (Tue, 08 Oct 2013) | 10 lines Fix some just-noticed problems: o Allow this to work with "nodevice random" by fixing where the MALLOC pool is defined. o Fix the explicit reseed code. This was correct as submitted, but in the project branch doesn't need to set the "seeded" bit as this is done correctly in the "unblock" function. o Remove some debug ifdeffing. o Adjust comments. ------------------------------------------------------------------------ r256159 | markm | 2013-10-08 19:48:11 +0100 (Tue, 08 Oct 2013) | 6 lines Time to eat crow for me. I replaced the sx_* locks that Arthur used with regular mutexes; this turned out the be the wrong thing to do as the locks need to be sleepable. Revert this folly. # Submitted by: Arthur Mesh <arthurmesh@gmail.com> (In original diff) ------------------------------------------------------------------------ r256138 | des | 2013-10-08 12:05:26 +0100 (Tue, 08 Oct 2013) | 10 lines 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. ------------------------------------------------------------------------ r256135 | markm | 2013-10-08 07:54:52 +0100 (Tue, 08 Oct 2013) | 8 lines Debugging. My attempt at EVENTHANDLER(multiuser) was a failure; use EVENTHANDLER(mountroot) instead. This means we can't count on /var being present, so something will need to be done about harvesting /var/db/entropy/... . Some policy now needs to be sorted out, and a pre-sync cache needs to be written, but apart from that we are now ready to go. Over to review. ------------------------------------------------------------------------ r256094 | markm | 2013-10-06 23:45:02 +0100 (Sun, 06 Oct 2013) | 8 lines Snapshot. Looking pretty good; this mostly works now. New code includes: * Read cached entropy at startup, both from files and from loader(8) preloaded entropy. Failures are soft, but announced. Untested. * Use EVENTHANDLER to do above just before we go multiuser. Untested. ------------------------------------------------------------------------ r256088 | markm | 2013-10-06 14:01:42 +0100 (Sun, 06 Oct 2013) | 2 lines Fix up the man page for random(4). This mainly removes no-longer-relevant details about HW RNGs, reseeding explicitly and user-supplied entropy. ------------------------------------------------------------------------ r256087 | markm | 2013-10-06 13:43:42 +0100 (Sun, 06 Oct 2013) | 6 lines As userland writing to /dev/random is no more, remove the "better than nothing" bootstrap mode. Add SWI harvesting to the mix. My box seeds Yarrow by itself in a few seconds! YMMV; more to follow. ------------------------------------------------------------------------ r256086 | markm | 2013-10-06 13:40:32 +0100 (Sun, 06 Oct 2013) | 11 lines Debug run. This now works, except that the "live" sources haven't been tested. With all sources turned on, this unlocks itself in a couple of seconds! That is no my box, and there is no guarantee that this will be the case everywhere. * Cut debug prints. * Use the same locks/mutexes all the way through. * Be a tad more conservative about entropy estimates. ------------------------------------------------------------------------ r256084 | markm | 2013-10-06 13:35:29 +0100 (Sun, 06 Oct 2013) | 5 lines Don't use the "real" assembler mnemonics; older compilers may not understand them (like when building CURRENT on 9.x). # Submitted by: Konstantin Belousov <kostikbel@gmail.com> ------------------------------------------------------------------------ r256081 | markm | 2013-10-06 10:55:28 +0100 (Sun, 06 Oct 2013) | 12 lines SNAPSHOT. Simplify the malloc pools; We only need one for this device. Simplify the harvest queue. Marginally improve the entropy pool hashing, making it a bit faster in the process. Connect up the hardware "live" source harvesting. This is simplistic for now, and will need to be made rate-adaptive. All of the above passes a compile test but needs to be debugged. ------------------------------------------------------------------------ r256042 | markm | 2013-10-04 07:55:06 +0100 (Fri, 04 Oct 2013) | 25 lines Snapshot. This passes the build test, but has not yet been finished or debugged. Contains: * Refactor the hardware RNG CPU instruction sources to feed into the software mixer. This is unfinished. The actual harvesting needs to be sorted out. Modified by me (see below). * Remove 'frac' parameter from random_harvest(). This was never used and adds extra code for no good reason. * Remove device write entropy harvesting. This provided a weak attack vector, was not very good at bootstrapping the device. To follow will be a replacement explicit reseed knob. * Separate out all the RANDOM_PURE sources into separate harvest entities. This adds some secuity in the case where more than one is present. * Review all the code and fix anything obviously messy or inconsistent. Address som review concerns while I'm here, like rename the pseudo-rng to 'dummy'. # Submitted by: Arthur Mesh <arthurmesh@gmail.com> (the first item) ------------------------------------------------------------------------ r255319 | markm | 2013-09-06 18:51:52 +0100 (Fri, 06 Sep 2013) | 4 lines Yarrow wants entropy estimations to be conservative; the usual idea is that if you are certain you have N bits of entropy, you declare N/2. ------------------------------------------------------------------------ r255075 | markm | 2013-08-30 18:47:53 +0100 (Fri, 30 Aug 2013) | 4 lines Remove short-lived idea; thread to harvest (eg) RDRAND enropy into the usual harvest queues. It was a nifty idea, but too heavyweight. # Submitted by: Arthur Mesh <arthurmesh@gmail.com> ------------------------------------------------------------------------ r255071 | markm | 2013-08-30 12:42:57 +0100 (Fri, 30 Aug 2013) | 4 lines Separate out the Software RNG entropy harvesting queue and thread into its own files. # Submitted by: Arthur Mesh <arthurmesh@gmail.com> ------------------------------------------------------------------------ r254934 | markm | 2013-08-26 20:07:03 +0100 (Mon, 26 Aug 2013) | 2 lines Remove the short-lived namei experiment. ------------------------------------------------------------------------ r254928 | markm | 2013-08-26 19:35:21 +0100 (Mon, 26 Aug 2013) | 2 lines Snapshot; Do some running repairs on entropy harvesting. More needs to follow. ------------------------------------------------------------------------ r254927 | markm | 2013-08-26 19:29:51 +0100 (Mon, 26 Aug 2013) | 15 lines Snapshot of current work; 1) Clean up namespace; only use "Yarrow" where it is Yarrow-specific or close enough to the Yarrow algorithm. For the rest use a neutral name. 2) Tidy up headers; put private stuff in private places. More could be done here. 3) Streamline the hashing/encryption; no need for a 256-bit counter; 128 bits will last for long enough. There are bits of debug code lying around; these will be removed at a later stage. ------------------------------------------------------------------------ r254784 | markm | 2013-08-24 14:54:56 +0100 (Sat, 24 Aug 2013) | 39 lines 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> Submitted by: Dag-Erling Smørgrav <des@FreeBSD.org>, Arthur Mesh <arthurmesh@gmail.com> Reviewed by: des@FreeBSD.org Approved by: re (delphij) Approved by: secteam (des,delphij)
331 lines
9.8 KiB
Groff
331 lines
9.8 KiB
Groff
.\" Copyright (c) 2001-2013 Mark R V Murray. All rights reserved.
|
|
.\"
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
.\" modification, are permitted provided that the following conditions
|
|
.\" are met:
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
.\"
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
.\" SUCH DAMAGE.
|
|
.\"
|
|
.\" $FreeBSD$
|
|
.\"
|
|
.Dd October 12, 2013
|
|
.Dt RANDOM 4
|
|
.Os
|
|
.Sh NAME
|
|
.Nm random
|
|
.Nd the entropy device
|
|
.Sh SYNOPSIS
|
|
.Cd "device random"
|
|
.Sh DESCRIPTION
|
|
The
|
|
.Nm
|
|
device
|
|
returns an endless supply of random bytes when read.
|
|
It also accepts and reads data
|
|
as any ordinary (and willing) file,
|
|
but discards data written to it.
|
|
The device will probe for
|
|
certain hardware entropy sources,
|
|
and use these in preference to the fallback,
|
|
which is a generator implemented in software.
|
|
.Pp
|
|
The software generator will start in an
|
|
.Em unseeded
|
|
state, and will block reads until
|
|
it is (re)seeded.
|
|
This may cause trouble at system boot
|
|
when keys and the like
|
|
are generated from
|
|
/dev/random
|
|
so steps should be taken to ensure a
|
|
reseed as soon as possible.
|
|
The
|
|
.Xr sysctl 8
|
|
controlling the
|
|
.Em seeded
|
|
status (see below) may be used
|
|
if security is not an issue
|
|
or for convenience
|
|
during setup or development.
|
|
.Pp
|
|
This initial seeding
|
|
of random number generators
|
|
is a bootstrapping problem
|
|
that needs very careful attention.
|
|
In some cases,
|
|
it may be difficult
|
|
to find enough randomness
|
|
to seed a random number generator
|
|
until a system is fully operational,
|
|
but the system requires random numbers
|
|
to become fully operational.
|
|
It is (or more accurately should be)
|
|
critically important that the
|
|
.Nm
|
|
device is seeded
|
|
before the first time it is used.
|
|
In the case where a dummy or "blocking-only"
|
|
device is used,
|
|
it is the responsibility
|
|
of the system architect
|
|
to ensure that no blocking reads
|
|
hold up critical processes.
|
|
.Pp
|
|
To see the current settings of the software
|
|
.Nm
|
|
device, use the command line:
|
|
.Pp
|
|
.Dl sysctl kern.random
|
|
.Pp
|
|
which results in something like:
|
|
.Bd -literal -offset indent
|
|
kern.random.adaptors: yarrow,dummy
|
|
kern.random.active_adaptor: yarrow
|
|
kern.random.yarrow.gengateinterval: 10
|
|
kern.random.yarrow.bins: 10
|
|
kern.random.yarrow.fastthresh: 96
|
|
kern.random.yarrow.slowthresh: 128
|
|
kern.random.yarrow.slowoverthresh: 2
|
|
kern.random.sys.seeded: 1
|
|
kern.random.sys.harvest.ethernet: 1
|
|
kern.random.sys.harvest.point_to_point: 1
|
|
kern.random.sys.harvest.interrupt: 1
|
|
kern.random.sys.harvest.swi: 1
|
|
.Ed
|
|
.Pp
|
|
Other than
|
|
.Dl kern.random.adaptors
|
|
all settings are read/write.
|
|
.Pp
|
|
The
|
|
.Va kern.random.sys.seeded
|
|
variable indicates whether or not the
|
|
.Nm
|
|
device is in an acceptably secure state
|
|
as a result of reseeding.
|
|
If set to 0,
|
|
the device will block (on read)
|
|
until the next reseed
|
|
as a result of entropy harvesting.
|
|
A reseed will set the value to 1 (non-blocking).
|
|
.Pp
|
|
The
|
|
.Va kern.random.sys.harvest.ethernet
|
|
variable is used to select LAN traffic as an entropy source.
|
|
A 0 (zero) value means that LAN traffic
|
|
is not considered as an entropy source.
|
|
Set the variable to 1 (one)
|
|
if you wish to use LAN traffic for entropy harvesting.
|
|
.Pp
|
|
The
|
|
.Va kern.random.sys.harvest.point_to_point
|
|
variable is used to select serial line traffic as an entropy source.
|
|
(Serial line traffic includes PPP, SLIP and all tun0 traffic.)
|
|
A 0 (zero) value means such traffic
|
|
is not considered as an entropy source.
|
|
Set the variable to 1 (one)
|
|
if you wish to use it for entropy harvesting.
|
|
.Pp
|
|
The
|
|
.Va kern.random.sys.harvest.interrupt
|
|
variable is used to select hardware interrupts
|
|
as an entropy source.
|
|
A 0 (zero) value means hardware interrupts
|
|
are not considered as an entropy source.
|
|
Set the variable to 1 (one)
|
|
if you wish to use them for entropy harvesting.
|
|
All hardware interrupt harvesting is set up by the
|
|
individual device drivers.
|
|
.Pp
|
|
The
|
|
.Va kern.random.sys.harvest.swi
|
|
variable is used to select software interrupts
|
|
as an entropy source.
|
|
A 0 (zero) value means software interrupts
|
|
are not considered as an entropy source.
|
|
Set the variable to 1 (one)
|
|
if you wish to use them for entropy harvesting.
|
|
.Pp
|
|
The other variables are explained in the paper describing the
|
|
.Em Yarrow
|
|
algorithm at
|
|
.Pa http://www.schneier.com/yarrow.html .
|
|
.Pp
|
|
These variables are all limited
|
|
in terms of the values they may contain:
|
|
.Bl -tag -width "kern.random.yarrow.gengateinterval" -compact -offset indent
|
|
.It Va kern.random.yarrow.gengateinterval
|
|
.Bq 4..64
|
|
.It Va kern.random.yarrow.bins
|
|
.Bq 2..16
|
|
.It Va kern.random.yarrow.fastthresh
|
|
.Bq 64..256
|
|
.It Va kern.random.yarrow.slowthresh
|
|
.Bq 64..256
|
|
.It Va kern.random.yarrow.slowoverthresh
|
|
.Bq 1..5
|
|
.El
|
|
.Pp
|
|
Internal
|
|
.Xr sysctl 3
|
|
handlers force the above variables
|
|
into the stated ranges.
|
|
.Sh RANDOMNESS
|
|
The use of randomness in the field of computing
|
|
is a rather subtle issue because randomness means
|
|
different things to different people.
|
|
Consider generating a password randomly,
|
|
simulating a coin tossing experiment or
|
|
choosing a random back-off period when a server does not respond.
|
|
Each of these tasks requires random numbers,
|
|
but the random numbers in each case have different requirements.
|
|
.Pp
|
|
Generation of passwords, session keys and the like
|
|
requires cryptographic randomness.
|
|
A cryptographic random number generator should be designed
|
|
so that its output is difficult to guess,
|
|
even if a lot of auxiliary information is known
|
|
(such as when it was seeded, subsequent or previous output, and so on).
|
|
On
|
|
.Fx ,
|
|
seeding for cryptographic random number generators is provided by the
|
|
.Nm
|
|
device,
|
|
which provides real randomness.
|
|
The
|
|
.Xr arc4random 3
|
|
library call provides a pseudo-random sequence
|
|
which is generally reckoned to be suitable for
|
|
simple cryptographic use.
|
|
The OpenSSL library also provides functions for managing randomness
|
|
via functions such as
|
|
.Xr RAND_bytes 3
|
|
and
|
|
.Xr RAND_add 3 .
|
|
Note that OpenSSL uses the
|
|
.Nm
|
|
device for seeding automatically.
|
|
.Pp
|
|
Randomness for simulation is required in engineering or
|
|
scientific software and games.
|
|
The first requirement of these applications is
|
|
that the random numbers produced conform to some well-known,
|
|
usually uniform, distribution.
|
|
The sequence of numbers should also appear numerically uncorrelated,
|
|
as simulation often assumes independence of its random inputs.
|
|
Often it is desirable to reproduce
|
|
the results of a simulation exactly,
|
|
so that if the generator is seeded in the same way,
|
|
it should produce the same results.
|
|
A peripheral concern for simulation is
|
|
the speed of a random number generator.
|
|
.Pp
|
|
Another issue in simulation is
|
|
the size of the state associated with the random number generator, and
|
|
how frequently it repeats itself.
|
|
For example,
|
|
a program which shuffles a pack of cards should have 52!\& possible outputs,
|
|
which requires the random number generator to have 52!\& starting states.
|
|
This means the seed should have at least log_2(52!) ~ 226 bits of state
|
|
if the program is to stand a chance of outputting all possible sequences,
|
|
and the program needs some unbiased way of generating these bits.
|
|
Again,
|
|
the
|
|
.Nm
|
|
device could be used for seeding here,
|
|
but in practice, smaller seeds are usually considered acceptable.
|
|
.Pp
|
|
.Fx
|
|
provides two families of functions which are considered
|
|
suitable for simulation.
|
|
The
|
|
.Xr random 3
|
|
family of functions provides a random integer
|
|
between 0 to
|
|
.if t 2\u\s731\s10\d\(mi1.
|
|
.if n (2**31)\(mi1.
|
|
The functions
|
|
.Xr srandom 3 ,
|
|
.Xr initstate 3
|
|
and
|
|
.Xr setstate 3
|
|
are provided for deterministically setting
|
|
the state of the generator and
|
|
the function
|
|
.Xr srandomdev 3
|
|
is provided for setting the state via the
|
|
.Nm
|
|
device.
|
|
The
|
|
.Xr drand48 3
|
|
family of functions are also provided,
|
|
which provide random floating point numbers in various ranges.
|
|
.Pp
|
|
Randomness that is used for collision avoidance
|
|
(for example, in certain network protocols)
|
|
has slightly different semantics again.
|
|
It is usually expected that the numbers will be uniform,
|
|
as this produces the lowest chances of collision.
|
|
Here again,
|
|
the seeding of the generator is very important,
|
|
as it is required that different instances of
|
|
the generator produce independent sequences.
|
|
However, the guessability or reproducibility of the sequence is unimportant,
|
|
unlike the previous cases.
|
|
.Pp
|
|
.Fx
|
|
does also provide the traditional
|
|
.Xr rand 3
|
|
library call,
|
|
for compatibility purposes.
|
|
However,
|
|
it is known to be poor for simulation and
|
|
absolutely unsuitable for cryptographic purposes,
|
|
so its use is discouraged.
|
|
.Sh FILES
|
|
.Bl -tag -width ".Pa /dev/random"
|
|
.It Pa /dev/random
|
|
.El
|
|
.Sh SEE ALSO
|
|
.Xr arc4random 3 ,
|
|
.Xr drand48 3 ,
|
|
.Xr rand 3 ,
|
|
.Xr RAND_add 3 ,
|
|
.Xr RAND_bytes 3 ,
|
|
.Xr random 3 ,
|
|
.Xr sysctl 8
|
|
.Sh HISTORY
|
|
A
|
|
.Nm
|
|
device appeared in
|
|
.Fx 2.2 .
|
|
The early version was taken from Theodore Ts'o's entropy driver for Linux.
|
|
The current software implementation,
|
|
introduced in
|
|
.Fx 5.0 ,
|
|
is a complete rewrite by
|
|
.An Mark R V Murray ,
|
|
and is an implementation of the
|
|
.Em Yarrow
|
|
algorithm by Bruce Schneier,
|
|
.Em et al .
|
|
Significant infrastructure work was done by Arthur Mesh.
|
|
.Pp
|
|
The author gratefully acknowledges
|
|
significant assistance from VIA Technologies, Inc.
|