/* * random.c -- A strong random number generator * * Copyright Matt Mackall <mpm@selenic.com>, 2003, 2004, 2005 * * Copyright Theodore Ts'o, 1994, 1995, 1996, 1997, 1998, 1999.  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, and the entire permission notice in its entirety, *    including the disclaimer of warranties. * 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. * 3. The name of the author may not be used to endorse or promote *    products derived from this software without specific prior *    written permission. * * ALTERNATIVELY, this product may be distributed under the terms of * the GNU General Public License, in which case the provisions of the GPL are * required INSTEAD OF the above restrictions.  (This clause is * necessary due to a potential bad interaction between the GPL and * the restrictions contained in a BSD-style copyright.) * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF * WHICH ARE HEREBY DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR 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 NOT ADVISED OF THE POSSIBILITY OF SUCH * DAMAGE. */ /* * (now, with legal B.S. out of the way.....) * * This routine gathers environmental noise from device drivers, etc., * and returns good random numbers, suitable for cryptographic use. * Besides the obvious cryptographic uses, these numbers are also good * for seeding TCP sequence numbers, and other places where it is * desirable to have numbers which are not only random, but hard to * predict by an attacker. * * Theory of operation * =================== * * Computers are very predictable devices.  Hence it is extremely hard * to produce truly random numbers on a computer --- as opposed to * pseudo-random numbers, which can easily generated by using a * algorithm.  Unfortunately, it is very easy for attackers to guess * the sequence of pseudo-random number generators, and for some * applications this is not acceptable.  So instead, we must try to * gather "environmental noise" from the computer's environment, which * must be hard for outside attackers to observe, and use that to * generate random numbers.  In a Unix environment, this is best done * from inside the kernel. * * Sources of randomness from the environment include inter-keyboard * timings, inter-interrupt timings from some interrupts, and other * events which are both (a) non-deterministic and (b) hard for an * outside observer to measure.  Randomness from these sources are * added to an "entropy pool", which is mixed using a CRC-like function. * This is not cryptographically strong, but it is adequate assuming * the randomness is not chosen maliciously, and it is fast enough that * the overhead of doing it on every interrupt is very reasonable. * As random bytes are mixed into the entropy pool, the routines keep * an *estimate* of how many bits of randomness have been stored into * the random number generator's internal state. * * When random bytes are desired, they are obtained by taking the SHA * hash of the contents of the "entropy pool".  The SHA hash avoids * exposing the internal state of the entropy pool.  It is believed to * be computationally infeasible to derive any useful information * about the input of SHA from its output.  Even if it is possible to * analyze SHA in some clever way, as long as the amount of data * returned from the generator is less than the inherent entropy in * the pool, the output data is totally unpredictable.  For this * reason, the routine decreases its internal estimate of how many * bits of "true randomness" are contained in the entropy pool as it * outputs random numbers. * * If this estimate goes to zero, the routine can still generate * random numbers; however, an attacker may (at least in theory) be * able to infer the future output of the generator from prior * outputs.  This requires successful cryptanalysis of SHA, which is * not believed to be feasible, but there is a remote possibility. * Nonetheless, these numbers should be useful for the vast majority * of purposes. * * Exported interfaces ---- output * =============================== * * There are three exported interfaces; the first is one designed to * be used from within the kernel: * * 	void get_random_bytes(void *buf, int nbytes); * * This interface will return the requested number of random bytes, * and place it in the requested buffer. * * The two other interfaces are two character devices /dev/random and * /dev/urandom.  /dev/random is suitable for use when very high * quality randomness is desired (for example, for key generation or * one-time pads), as it will only return a maximum of the number of * bits of randomness (as estimated by the random number generator) * contained in the entropy pool. * * The /dev/urandom device does not have this limit, and will return * as many bytes as are requested.  As more and more random bytes are * requested without giving time for the entropy pool to recharge, * this will result in random numbers that are merely cryptographically * strong.  For many applications, however, this is acceptable. * * Exported interfaces ---- input * ============================== * * The current exported interfaces for gathering environmental noise * from the devices are: * * 	void add_input_randomness(unsigned int type, unsigned int code, *                                unsigned int value); * 	void add_interrupt_randomness(int irq); * * add_input_randomness() uses the input layer interrupt timing, as well as * the event type information from the hardware. * * add_interrupt_randomness() uses the inter-interrupt timing as random * inputs to the entropy pool.  Note that not all interrupts are good * sources of randomness!  For example, the timer interrupts is not a * good choice, because the periodicity of the interrupts is too * regular, and hence predictable to an attacker.  Disk interrupts are * a better measure, since the timing of the disk interrupts are more * unpredictable. * * All of these routines try to estimate how many bits of randomness a * particular randomness source.  They do this by keeping track of the * first and second order deltas of the event timings. * * Ensuring unpredictability at system startup * ============================================ * * When any operating system starts up, it will go through a sequence * of actions that are fairly predictable by an adversary, especially * if the start-up does not involve interaction with a human operator. * This reduces the actual number of bits of unpredictability in the * entropy pool below the value in entropy_count.  In order to * counteract this effect, it helps to carry information in the * entropy pool across shut-downs and start-ups.  To do this, put the * following lines an appropriate script which is run during the boot * sequence: * *	echo "Initializing random number generator..." *	random_seed=/var/run/random-seed *	# Carry a random seed from start-up to start-up *	# Load and then save the whole entropy pool *	if [ -f $random_seed ]; then *		cat $random_seed >/dev/urandom *	else *		touch $random_seed *	fi *	chmod 600 $random_seed *	dd if=/dev/urandom of=$random_seed count=1 bs=512 * * and the following lines in an appropriate script which is run as * the system is shutdown: * *	# Carry a random seed from shut-down to start-up *	# Save the whole entropy pool *	echo "Saving random seed..." *	random_seed=/var/run/random-seed *	touch $random_seed *	chmod 600 $random_seed *	dd if=/dev/urandom of=$random_seed count=1 bs=512 * * For example, on most modern systems using the System V init * scripts, such code fragments would be found in * /etc/rc.d/init.d/random.  On older Linux systems, the correct script * location might be in /etc/rcb.d/rc.local or /etc/rc.d/rc.0. * * Effectively, these commands cause the contents of the entropy pool * to be saved at shut-down time and reloaded into the entropy pool at * start-up.  (The 'dd' in the addition to the bootup script is to * make sure that /etc/random-seed is different for every start-up, * even if the system crashes without executing rc.0.)  Even with * complete knowledge of the start-up activities, predicting the state * of the entropy pool requires knowledge of the previous history of * the system. * * Configuring the /dev/random driver under Linux * ============================================== * * The /dev/random driver under Linux uses minor numbers 8 and 9 of * the /dev/mem major number (#1).  So if your system does not have * /dev/random and /dev/urandom created already, they can be created * by using the commands: * * 	mknod /dev/random c 1 8 * 	mknod /dev/urandom c 1 9 * * Acknowledgements: * ================= * * Ideas for constructing this random number generator were derived * from Pretty Good Privacy's random number generator, and from private * discussions with Phil Karn.  Colin Plumb provided a faster random * number generator, which speed up the mixing function of the entropy * pool, taken from PGPfone.  Dale Worley has also contributed many * useful ideas and suggestions to improve this driver. * * Any flaws in the design are solely my responsibility, and should * not be attributed to the Phil, Colin, or any of authors of PGP. * * Further background information on this topic may be obtained from * RFC 1750, "Randomness Recommendations for Security", by Donald * Eastlake, Steve Crocker, and Jeff Schiller. */ #include <linux/utsname.h>#include <linux/config.h>#include <linux/module.h>#include <linux/kernel.h>#include <linux/major.h>#include <linux/string.h>#include <linux/fcntl.h>#include <linux/slab.h>#include <linux/random.h>#include <linux/poll.h>#include <linux/init.h>#include <linux/fs.h>#include <linux/genhd.h>#include <linux/interrupt.h>#include <linux/spinlock.h>#include <linux/percpu.h>#include <linux/cryptohash.h> #include <asm/processor.h>#include <asm/uaccess.h>#include <asm/irq.h>#include <asm/io.h> /* * Configuration information */#define INPUT_POOL_WORDS 128#define OUTPUT_POOL_WORDS 32#define SEC_XFER_SIZE 512 /* * The minimum number of bits of entropy before we wake up a read on * /dev/random.  Should be enough to do a significant reseed. */static int random_read_wakeup_thresh = 64; /* * If the entropy count falls under this number of bits, then we * should wake up processes which are selecting or polling on write * access to /dev/random. */static int random_write_wakeup_thresh = 128; /* * When the input pool goes over trickle_thresh, start dropping most * samples to avoid wasting CPU time and reduce lock contention. */ static int trickle_thresh __read_mostly = INPUT_POOL_WORDS * 28; static DEFINE_PER_CPU(int, trickle_count) = 0; /* * A pool of size .poolwords is stirred with a primitive polynomial * of degree .poolwords over GF(2).  The taps for various sizes are * defined below.  They are chosen to be evenly spaced (minimum RMS * distance from evenly spaced; the numbers in the comments are a * scaled squared error sum) except for the last tap, which is 1 to * get the twisting happening as fast as possible. */static struct poolinfo {	int poolwords;	int tap1, tap2, tap3, tap4, tap5;} poolinfo_table[] = {	/* x^128 + x^103 + x^76 + x^51 +x^25 + x + 1 -- 105 */	{ 128,	103,	76,	51,	25,	1 },	/* x^32 + x^26 + x^20 + x^14 + x^7 + x + 1 -- 15 */	{ 32,	26,	20,	14,	7,	1 },#if 0	/* x^2048 + x^1638 + x^1231 + x^819 + x^411 + x + 1  -- 115 */	{ 2048,	1638,	1231,	819,	411,	1 }, 	/* x^1024 + x^817 + x^615 + x^412 + x^204 + x + 1 -- 290 */	{ 1024,	817,	615,	412,	204,	1 }, 	/* x^1024 + x^819 + x^616 + x^410 + x^207 + x^2 + 1 -- 115 */	{ 1024,	819,	616,	410,	207,	2 }, 	/* x^512 + x^411 + x^308 + x^208 + x^104 + x + 1 -- 225 */	{ 512,	411,	308,	208,	104,	1 }, 	/* x^512 + x^409 + x^307 + x^206 + x^102 + x^2 + 1 -- 95 */	{ 512,	409,	307,	206,	102,	2 },	/* x^512 + x^409 + x^309 + x^205 + x^103 + x^2 + 1 -- 95 */	{ 512,	409,	309,	205,	103,	2 }, 	/* x^256 + x^205 + x^155 + x^101 + x^52 + x + 1 -- 125 */	{ 256,	205,	155,	101,	52,	1 }, 	/* x^128 + x^103 + x^78 + x^51 + x^27 + x^2 + 1 -- 70 */	{ 128,	103,	78,	51,	27,	2 }, 	/* x^64 + x^52 + x^39 + x^26 + x^14 + x + 1 -- 15 */	{ 64,	52,	39,	26,	14,	1 },#endif}; #define POOLBITS	poolwords*32#define POOLBYTES	poolwords*4 /* * For the purposes of better mixing, we use the CRC-32 polynomial as * well to make a twisted Generalized Feedback Shift Reigster * * (See M. Matsumoto & Y. Kurita, 1992.  Twisted GFSR generators.  ACM * Transactions on Modeling and Computer Simulation 2(3):179-194. * Also see M. Matsumoto & Y. Kurita, 1994.  Twisted GFSR generators * II.  ACM Transactions on Mdeling and Computer Simulation 4:254-266) * * Thanks to Colin Plumb for suggesting this. * * We have not analyzed the resultant polynomial to prove it primitive; * in fact it almost certainly isn't.  Nonetheless, the irreducible factors * of a random large-degree polynomial over GF(2) are more than large enough * that periodicity is not a concern. * * The input hash is much less sensitive than the output hash.  All * that we want of it is that it be a good non-cryptographic hash; * i.e. it not produce collisions when fed "random" data of the sort * we expect to see.  As long as the pool state differs for different * inputs, we have preserved the input entropy and done a good job. * The fact that an intelligent attacker can construct inputs that * will produce controlled alterations to the pool's state is not * important because we don't consider such inputs to contribute any * randomness.  The only property we need with respect to them is that * the attacker can't increase his/her knowledge of the pool's state. * Since all additions are reversible (knowing the final state and the * input, you can reconstruct the initial state), if an attacker has * any uncertainty about the initial state, he/she can only shuffle * that uncertainty about, but never cause any collisions (which would * decrease the uncertainty). * * The chosen system lets the state of the pool be (essentially) the input * modulo the generator polymnomial.  Now, for random primitive polynomials, * this is a universal class of hash functions, meaning that the chance * of a collision is limited by the attacker's knowledge of the generator * polynomail, so if it is chosen at random, an attacker can never force * a collision.  Here, we use a fixed polynomial, but we *can* assume that * ###--> it is unknown to the processes generating the input entropy. <-### * Because of this important property, this is a good, collision-resistant * hash; hash collisions will occur no more often than chance. */ /* * Static global variables */static DECLARE_WAIT_QUEUE_HEAD(random_read_wait);static DECLARE_WAIT_QUEUE_HEAD(random_write_wait); #if 0static int debug = 0;module_param(debug, bool, 0644);#define DEBUG_ENT(fmt, arg...) do { if (debug) \	printk(KERN_DEBUG "random %04d %04d %04d: " \	fmt,\	input_pool.entropy_count,\	blocking_pool.entropy_count,\	nonblocking_pool.entropy_count,\	## arg); } while (0)#else#define DEBUG_ENT(fmt, arg...) do {} while (0)#endif /********************************************************************** * * OS independent entropy store.   Here are the functions which handle * storing entropy in an entropy pool. * **********************************************************************/ struct entropy_store;struct entropy_store {	/* mostly-read data: */	struct poolinfo *poolinfo;	__u32 *pool;	const char *name;	int limit;	struct entropy_store *pull; 	/* read-write data: */	spinlock_t lock ____cacheline_aligned_in_smp;	unsigned add_ptr;	int entropy_count;	int input_rotate;}; static __u32 input_pool_data[INPUT_POOL_WORDS];static __u32 blocking_pool_data[OUTPUT_POOL_WORDS];static __u32 nonblocking_pool_data[OUTPUT_POOL_WORDS]; static struct entropy_store input_pool = {	.poolinfo = &poolinfo_table[0],	.name = "input",	.limit = 1,	.lock = SPIN_LOCK_UNLOCKED,	.pool = input_pool_data}; static struct entropy_store blocking_pool = {	.poolinfo = &poolinfo_table[1],	.name = "blocking",	.limit = 1,	.pull = &input_pool,	.lock = SPIN_LOCK_UNLOCKED,	.pool = blocking_pool_data}; static struct entropy_store nonblocking_pool = {	.poolinfo = &poolinfo_table[1],	.name = "nonblocking",	.pull = &input_pool,	.lock = SPIN_LOCK_UNLOCKED,	.pool = nonblocking_pool_data}; /* * This function adds a byte into the entropy "pool".  It does not * update the entropy estimate.  The caller should call * credit_entropy_store if this is appropriate. * * The pool is stirred with a primitive polynomial of the appropriate * degree, and then twisted.  We twist by three bits at a time because * it's cheap to do so and helps slightly in the expected case where * the entropy is concentrated in the low-order bits. */static void __add_entropy_words(struct entropy_store *r, const __u32 *in,				int nwords, __u32 out[16]){	static __u32 const twist_table[8] = {		0x00000000, 0x3b6e20c8, 0x76dc4190, 0x4db26158,		0xedb88320, 0xd6d6a3e8, 0x9b64c2b0, 0xa00ae278 };	unsigned long i, add_ptr, tap1, tap2, tap3, tap4, tap5;	int new_rotate, input_rotate;	int wordmask = r->poolinfo->poolwords - 1;	__u32 w, next_w;	unsigned long flags; 	/* Taps are constant, so we can load them without holding r->lock.  */	tap1 = r->poolinfo->tap1;	tap2 = r->poolinfo->tap2;	tap3 = r->poolinfo->tap3;	tap4 = r->poolinfo->tap4;	tap5 = r->poolinfo->tap5;	next_w = *in++; 	spin_lock_irqsave(&r->lock, flags);	prefetch_range(r->pool, wordmask);	input_rotate = r->input_rotate;	add_ptr = r->add_ptr; 	while (nwords--) {		w = rol32(next_w, input_rotate);		if (nwords > 0)			next_w = *in++;		i = add_ptr = (add_ptr - 1) & wordmask;		/*		 * Normally, we add 7 bits of rotation to the pool.		 * At the beginning of the pool, add an extra 7 bits		 * rotation, so that successive passes spread the		 * input bits across the pool evenly.		 */		new_rotate = input_rotate + 14;		if (i)			new_rotate = input_rotate + 7;		input_rotate = new_rotate & 31; 		/* XOR in the various taps */		w ^= r->pool[(i + tap1) & wordmask];		w ^= r->pool[(i + tap2) & wordmask];		w ^= r->pool[(i + tap3) & wordmask];		w ^= r->pool[(i + tap4) & wordmask];		w ^= r->pool[(i + tap5) & wordmask];		w ^= r->pool[i];		r->pool[i] = (w >> 3) ^ twist_table[w & 7];	}

Lines 1–500 of 1660. Load more