2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* random.c -- A strong random number generator
|
|
|
|
*
|
random: invalidate batched entropy after crng init
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
2017-06-08 07:45:31 +08:00
|
|
|
* Copyright (C) 2017 Jason A. Donenfeld <Jason@zx2c4.com>. All
|
|
|
|
* Rights Reserved.
|
|
|
|
*
|
2005-04-17 06:25:56 +08:00
|
|
|
* Copyright Matt Mackall <mpm@selenic.com>, 2003, 2004, 2005
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* 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:
|
|
|
|
*
|
2012-07-04 23:16:01 +08:00
|
|
|
* void add_device_randomness(const void *buf, unsigned int size);
|
2005-04-17 06:20:36 +08:00
|
|
|
* void add_input_randomness(unsigned int type, unsigned int code,
|
|
|
|
* unsigned int value);
|
2012-07-02 19:52:16 +08:00
|
|
|
* void add_interrupt_randomness(int irq, int irq_flags);
|
random: update interface comments to reflect reality
At present, the comment header in random.c makes no mention of
add_disk_randomness, and instead, suggests that disk activity adds to the
random pool by way of add_interrupt_randomness, which appears to not have
been the case since sometime prior to the existence of git, and even prior
to bitkeeper. Didn't look any further back. At least, as far as I can
tell, there are no storage drivers setting IRQF_SAMPLE_RANDOM, which is a
requirement for add_interrupt_randomness to trigger, so the only way for a
disk to contribute entropy is by way of add_disk_randomness. Update
comments accordingly, complete with special mention about solid state
drives being a crappy source of entropy (see e2e1a148bc for reference).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-02-21 18:43:10 +08:00
|
|
|
* void add_disk_randomness(struct gendisk *disk);
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2012-07-04 23:16:01 +08:00
|
|
|
* add_device_randomness() is for adding data to the random pool that
|
|
|
|
* is likely to differ between two devices (or possibly even per boot).
|
|
|
|
* This would be things like MAC addresses or serial numbers, or the
|
|
|
|
* read-out of the RTC. This does *not* add any actual entropy to the
|
|
|
|
* pool, but it initializes the pool to different values for devices
|
|
|
|
* that might otherwise be identical and have very little entropy
|
|
|
|
* available to them (particularly common in the embedded world).
|
|
|
|
*
|
2005-04-17 06:20:36 +08:00
|
|
|
* add_input_randomness() uses the input layer interrupt timing, as well as
|
|
|
|
* the event type information from the hardware.
|
|
|
|
*
|
2012-07-02 19:52:16 +08:00
|
|
|
* add_interrupt_randomness() uses the interrupt timing as random
|
|
|
|
* inputs to the entropy pool. Using the cycle counters and the irq source
|
|
|
|
* as inputs, it feeds the randomness roughly once a second.
|
random: update interface comments to reflect reality
At present, the comment header in random.c makes no mention of
add_disk_randomness, and instead, suggests that disk activity adds to the
random pool by way of add_interrupt_randomness, which appears to not have
been the case since sometime prior to the existence of git, and even prior
to bitkeeper. Didn't look any further back. At least, as far as I can
tell, there are no storage drivers setting IRQF_SAMPLE_RANDOM, which is a
requirement for add_interrupt_randomness to trigger, so the only way for a
disk to contribute entropy is by way of add_disk_randomness. Update
comments accordingly, complete with special mention about solid state
drives being a crappy source of entropy (see e2e1a148bc for reference).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-02-21 18:43:10 +08:00
|
|
|
*
|
|
|
|
* add_disk_randomness() uses what amounts to the seek time of block
|
|
|
|
* layer request events, on a per-disk_devt basis, as input to the
|
|
|
|
* entropy pool. Note that high-speed solid state drives with very low
|
|
|
|
* seek times do not make for good sources of entropy, as their seek
|
|
|
|
* times are usually fairly consistent.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* 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/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>
|
2008-07-24 12:28:13 +08:00
|
|
|
#include <linux/mm.h>
|
2016-07-30 22:23:08 +08:00
|
|
|
#include <linux/nodemask.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/spinlock.h>
|
2014-06-15 11:38:36 +08:00
|
|
|
#include <linux/kthread.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/percpu.h>
|
|
|
|
#include <linux/cryptohash.h>
|
2009-06-18 19:50:21 +08:00
|
|
|
#include <linux/fips.h>
|
2012-07-02 19:52:16 +08:00
|
|
|
#include <linux/ptrace.h>
|
2013-10-03 13:08:15 +08:00
|
|
|
#include <linux/workqueue.h>
|
2013-08-30 15:39:53 +08:00
|
|
|
#include <linux/irq.h>
|
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
2014-07-17 16:13:05 +08:00
|
|
|
#include <linux/syscalls.h>
|
|
|
|
#include <linux/completion.h>
|
2016-05-21 08:01:00 +08:00
|
|
|
#include <linux/uuid.h>
|
2016-06-13 06:13:36 +08:00
|
|
|
#include <crypto/chacha20.h>
|
2009-01-11 16:35:42 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/processor.h>
|
2016-12-25 03:46:01 +08:00
|
|
|
#include <linux/uaccess.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/irq.h>
|
2012-07-02 19:52:16 +08:00
|
|
|
#include <asm/irq_regs.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <asm/io.h>
|
|
|
|
|
2012-07-05 04:19:30 +08:00
|
|
|
#define CREATE_TRACE_POINTS
|
|
|
|
#include <trace/events/random.h>
|
|
|
|
|
2014-06-15 09:43:13 +08:00
|
|
|
/* #define ADD_INTERRUPT_BENCH */
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Configuration information
|
|
|
|
*/
|
random: account for entropy loss due to overwrites
When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool. This means that unless the pool is
fully empty, we are currently *guaranteed* to overestimate the amount
of entropy in the pool!
Assuming Shannon entropy with zero correlations we end up with an
exponentally decaying value of new entropy added:
entropy <- entropy + (pool_size - entropy) *
(1 - exp(-add_entropy/pool_size))
However, calculations involving fractional exponentials are not
practical in the kernel, so apply a piecewise linearization:
For add_entropy <= pool_size/2 then
(1 - exp(-add_entropy/pool_size)) >= (add_entropy/pool_size)*0.7869...
... so we can approximate the exponential with
3/4*add_entropy/pool_size and still be on the
safe side by adding at most pool_size/2 at a time.
In order for the loop not to take arbitrary amounts of time if a bad
ioctl is received, terminate if we are within one bit of full. This
way the loop is guaranteed to terminate after no more than
log2(poolsize) iterations, no matter what the input value is. The
vast majority of the time the loop will be executed exactly once.
The piecewise linearization is very conservative, approaching 3/4 of
the usable input value for small inputs, however, our entropy
estimation is pretty weak at best, especially for small values; we
have no handle on correlation; and the Shannon entropy measure (Rényi
entropy of order 1) is not the correct one to use in the first place,
but rather the correct entropy measure is the min-entropy, the Rényi
entropy of infinite order.
As such, this conservatism seems more than justified.
This does introduce fractional bit values. I have left it to have 3
bits of fraction, so that with a pool of 2^12 bits the multiply in
credit_entropy_bits() can still fit into an int, as 2*(3+12) < 31. It
is definitely possible to allow for more fractional accounting, but
that multiply then would have to be turned into a 32*32 -> 64 multiply.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: DJ Johnston <dj.johnston@intel.com>
2013-09-11 11:16:17 +08:00
|
|
|
#define INPUT_POOL_SHIFT 12
|
|
|
|
#define INPUT_POOL_WORDS (1 << (INPUT_POOL_SHIFT-5))
|
|
|
|
#define OUTPUT_POOL_SHIFT 10
|
|
|
|
#define OUTPUT_POOL_WORDS (1 << (OUTPUT_POOL_SHIFT-5))
|
|
|
|
#define SEC_XFER_SIZE 512
|
|
|
|
#define EXTRACT_SIZE 10
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
2012-07-28 10:26:08 +08:00
|
|
|
#define LONGS(x) (((x) + sizeof(unsigned long) - 1)/sizeof(unsigned long))
|
|
|
|
|
2013-09-11 11:16:17 +08:00
|
|
|
/*
|
2013-10-03 09:10:35 +08:00
|
|
|
* To allow fractional bits to be tracked, the entropy_count field is
|
|
|
|
* denominated in units of 1/8th bits.
|
random: account for entropy loss due to overwrites
When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool. This means that unless the pool is
fully empty, we are currently *guaranteed* to overestimate the amount
of entropy in the pool!
Assuming Shannon entropy with zero correlations we end up with an
exponentally decaying value of new entropy added:
entropy <- entropy + (pool_size - entropy) *
(1 - exp(-add_entropy/pool_size))
However, calculations involving fractional exponentials are not
practical in the kernel, so apply a piecewise linearization:
For add_entropy <= pool_size/2 then
(1 - exp(-add_entropy/pool_size)) >= (add_entropy/pool_size)*0.7869...
... so we can approximate the exponential with
3/4*add_entropy/pool_size and still be on the
safe side by adding at most pool_size/2 at a time.
In order for the loop not to take arbitrary amounts of time if a bad
ioctl is received, terminate if we are within one bit of full. This
way the loop is guaranteed to terminate after no more than
log2(poolsize) iterations, no matter what the input value is. The
vast majority of the time the loop will be executed exactly once.
The piecewise linearization is very conservative, approaching 3/4 of
the usable input value for small inputs, however, our entropy
estimation is pretty weak at best, especially for small values; we
have no handle on correlation; and the Shannon entropy measure (Rényi
entropy of order 1) is not the correct one to use in the first place,
but rather the correct entropy measure is the min-entropy, the Rényi
entropy of infinite order.
As such, this conservatism seems more than justified.
This does introduce fractional bit values. I have left it to have 3
bits of fraction, so that with a pool of 2^12 bits the multiply in
credit_entropy_bits() can still fit into an int, as 2*(3+12) < 31. It
is definitely possible to allow for more fractional accounting, but
that multiply then would have to be turned into a 32*32 -> 64 multiply.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: DJ Johnston <dj.johnston@intel.com>
2013-09-11 11:16:17 +08:00
|
|
|
*
|
|
|
|
* 2*(ENTROPY_SHIFT + log2(poolbits)) must <= 31, or the multiply in
|
|
|
|
* credit_entropy_bits() needs to be 64 bits wide.
|
2013-09-11 11:16:17 +08:00
|
|
|
*/
|
|
|
|
#define ENTROPY_SHIFT 3
|
|
|
|
#define ENTROPY_BITS(r) ((r)->entropy_count >> ENTROPY_SHIFT)
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* The minimum number of bits of entropy before we wake up a read on
|
|
|
|
* /dev/random. Should be enough to do a significant reseed.
|
|
|
|
*/
|
2013-12-07 10:28:03 +08:00
|
|
|
static int random_read_wakeup_bits = 64;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
2013-12-07 10:28:03 +08:00
|
|
|
static int random_write_wakeup_bits = 28 * OUTPUT_POOL_WORDS;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
2013-09-23 04:04:19 +08:00
|
|
|
* Originally, we used a primitive polynomial of degree .poolwords
|
|
|
|
* over GF(2). The taps for various sizes are defined below. They
|
|
|
|
* were chosen to be evenly spaced except for the last tap, which is 1
|
|
|
|
* to get the twisting happening as fast as possible.
|
|
|
|
*
|
|
|
|
* For the purposes of better mixing, we use the CRC-32 polynomial as
|
|
|
|
* well to make a (modified) twisted Generalized Feedback Shift
|
|
|
|
* Register. (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
|
2013-11-30 03:58:06 +08:00
|
|
|
* GFSR generators II. ACM Transactions on Modeling and Computer
|
2013-09-23 04:04:19 +08:00
|
|
|
* Simulation 4:254-266)
|
|
|
|
*
|
|
|
|
* Thanks to Colin Plumb for suggesting this.
|
|
|
|
*
|
|
|
|
* The mixing operation is much less sensitive than the output hash,
|
|
|
|
* where we use SHA-1. All that we want of mixing operation 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).
|
|
|
|
*
|
|
|
|
* Our mixing functions were analyzed by Lacharme, Roeck, Strubel, and
|
|
|
|
* Videau in their paper, "The Linux Pseudorandom Number Generator
|
|
|
|
* Revisited" (see: http://eprint.iacr.org/2012/251.pdf). In their
|
|
|
|
* paper, they point out that we are not using a true Twisted GFSR,
|
|
|
|
* since Matsumoto & Kurita used a trinomial feedback polynomial (that
|
|
|
|
* is, with only three taps, instead of the six that we are using).
|
|
|
|
* As a result, the resulting polynomial is neither primitive nor
|
|
|
|
* irreducible, and hence does not have a maximal period over
|
|
|
|
* GF(2**32). They suggest a slight change to the generator
|
|
|
|
* polynomial which improves the resulting TGFSR polynomial to be
|
|
|
|
* irreducible, which we have made here.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
static struct poolinfo {
|
2013-09-11 11:16:17 +08:00
|
|
|
int poolbitshift, poolwords, poolbytes, poolbits, poolfracbits;
|
|
|
|
#define S(x) ilog2(x)+5, (x), (x)*4, (x)*32, (x) << (ENTROPY_SHIFT+5)
|
2005-04-17 06:20:36 +08:00
|
|
|
int tap1, tap2, tap3, tap4, tap5;
|
|
|
|
} poolinfo_table[] = {
|
2013-09-23 04:04:19 +08:00
|
|
|
/* was: x^128 + x^103 + x^76 + x^51 +x^25 + x + 1 */
|
|
|
|
/* x^128 + x^104 + x^76 + x^51 +x^25 + x + 1 */
|
|
|
|
{ S(128), 104, 76, 51, 25, 1 },
|
|
|
|
/* was: x^32 + x^26 + x^20 + x^14 + x^7 + x + 1 */
|
|
|
|
/* x^32 + x^26 + x^19 + x^14 + x^7 + x + 1 */
|
|
|
|
{ S(32), 26, 19, 14, 7, 1 },
|
2005-04-17 06:20:36 +08:00
|
|
|
#if 0
|
|
|
|
/* x^2048 + x^1638 + x^1231 + x^819 + x^411 + x + 1 -- 115 */
|
2013-09-11 11:16:17 +08:00
|
|
|
{ S(2048), 1638, 1231, 819, 411, 1 },
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* x^1024 + x^817 + x^615 + x^412 + x^204 + x + 1 -- 290 */
|
2013-09-11 11:16:17 +08:00
|
|
|
{ S(1024), 817, 615, 412, 204, 1 },
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* x^1024 + x^819 + x^616 + x^410 + x^207 + x^2 + 1 -- 115 */
|
2013-09-11 11:16:17 +08:00
|
|
|
{ S(1024), 819, 616, 410, 207, 2 },
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* x^512 + x^411 + x^308 + x^208 + x^104 + x + 1 -- 225 */
|
2013-09-11 11:16:17 +08:00
|
|
|
{ S(512), 411, 308, 208, 104, 1 },
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* x^512 + x^409 + x^307 + x^206 + x^102 + x^2 + 1 -- 95 */
|
2013-09-11 11:16:17 +08:00
|
|
|
{ S(512), 409, 307, 206, 102, 2 },
|
2005-04-17 06:20:36 +08:00
|
|
|
/* x^512 + x^409 + x^309 + x^205 + x^103 + x^2 + 1 -- 95 */
|
2013-09-11 11:16:17 +08:00
|
|
|
{ S(512), 409, 309, 205, 103, 2 },
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* x^256 + x^205 + x^155 + x^101 + x^52 + x + 1 -- 125 */
|
2013-09-11 11:16:17 +08:00
|
|
|
{ S(256), 205, 155, 101, 52, 1 },
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* x^128 + x^103 + x^78 + x^51 + x^27 + x^2 + 1 -- 70 */
|
2013-09-11 11:16:17 +08:00
|
|
|
{ S(128), 103, 78, 51, 27, 2 },
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* x^64 + x^52 + x^39 + x^26 + x^14 + x + 1 -- 15 */
|
2013-09-11 11:16:17 +08:00
|
|
|
{ S(64), 52, 39, 26, 14, 1 },
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Static global variables
|
|
|
|
*/
|
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(random_read_wait);
|
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(random_write_wait);
|
random: add async notification support to /dev/random
Add async notification support to /dev/random.
A little test case is below. Without this patch, you get:
$ ./async-random
Drained the pool
Found more randomness
With it, you get:
$ ./async-random
Drained the pool
SIGIO
Found more randomness
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <errno.h>
#include <fcntl.h>
static void handler(int sig)
{
printf("SIGIO\n");
}
int main(int argc, char **argv)
{
int fd, n, err, flags;
if(signal(SIGIO, handler) < 0){
perror("setting SIGIO handler");
exit(1);
}
fd = open("/dev/random", O_RDONLY);
if(fd < 0){
perror("open");
exit(1);
}
flags = fcntl(fd, F_GETFL);
if (flags < 0){
perror("getting flags");
exit(1);
}
flags |= O_NONBLOCK;
if (fcntl(fd, F_SETFL, flags) < 0){
perror("setting flags");
exit(1);
}
while((err = read(fd, &n, sizeof(n))) > 0) ;
if(err == 0){
printf("random returned 0\n");
exit(1);
}
else if(errno != EAGAIN){
perror("read");
exit(1);
}
flags |= O_ASYNC;
if (fcntl(fd, F_SETFL, flags) < 0){
perror("setting flags");
exit(1);
}
if (fcntl(fd, F_SETOWN, getpid()) < 0) {
perror("Setting SIGIO");
exit(1);
}
printf("Drained the pool\n");
read(fd, &n, sizeof(n));
printf("Found more randomness\n");
return(0);
}
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Matt Mackall <mpm@selenic.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-29 16:03:08 +08:00
|
|
|
static struct fasync_struct *fasync;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-06-09 18:19:39 +08:00
|
|
|
static DEFINE_SPINLOCK(random_ready_list_lock);
|
|
|
|
static LIST_HEAD(random_ready_list);
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
struct crng_state {
|
|
|
|
__u32 state[16];
|
|
|
|
unsigned long init_time;
|
|
|
|
spinlock_t lock;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct crng_state primary_crng = {
|
|
|
|
.lock = __SPIN_LOCK_UNLOCKED(primary_crng.lock),
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* crng_init = 0 --> Uninitialized
|
|
|
|
* 1 --> Initialized
|
|
|
|
* 2 --> Initialized from input_pool
|
|
|
|
*
|
|
|
|
* crng_init is protected by primary_crng->lock, and only increases
|
|
|
|
* its value (from 0->1->2).
|
|
|
|
*/
|
|
|
|
static int crng_init = 0;
|
2018-04-12 01:27:52 +08:00
|
|
|
#define crng_ready() (likely(crng_init > 1))
|
2016-06-13 06:13:36 +08:00
|
|
|
static int crng_init_cnt = 0;
|
2018-04-12 04:32:17 +08:00
|
|
|
static unsigned long crng_global_init_time = 0;
|
2016-06-13 06:13:36 +08:00
|
|
|
#define CRNG_INIT_CNT_THRESH (2*CHACHA20_KEY_SIZE)
|
2016-05-02 14:04:41 +08:00
|
|
|
static void _extract_crng(struct crng_state *crng,
|
2017-11-23 03:51:39 +08:00
|
|
|
__u32 out[CHACHA20_BLOCK_WORDS]);
|
2016-05-05 01:29:18 +08:00
|
|
|
static void _crng_backtrack_protect(struct crng_state *crng,
|
2017-11-23 03:51:39 +08:00
|
|
|
__u32 tmp[CHACHA20_BLOCK_WORDS], int used);
|
2016-06-13 06:13:36 +08:00
|
|
|
static void process_random_ready_list(void);
|
2017-06-08 16:16:59 +08:00
|
|
|
static void _get_random_bytes(void *buf, int nbytes);
|
2016-06-13 06:13:36 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/**********************************************************************
|
|
|
|
*
|
|
|
|
* OS independent entropy store. Here are the functions which handle
|
|
|
|
* storing entropy in an entropy pool.
|
|
|
|
*
|
|
|
|
**********************************************************************/
|
|
|
|
|
|
|
|
struct entropy_store;
|
|
|
|
struct entropy_store {
|
2008-04-29 16:03:01 +08:00
|
|
|
/* read-only data: */
|
random: account for entropy loss due to overwrites
When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool. This means that unless the pool is
fully empty, we are currently *guaranteed* to overestimate the amount
of entropy in the pool!
Assuming Shannon entropy with zero correlations we end up with an
exponentally decaying value of new entropy added:
entropy <- entropy + (pool_size - entropy) *
(1 - exp(-add_entropy/pool_size))
However, calculations involving fractional exponentials are not
practical in the kernel, so apply a piecewise linearization:
For add_entropy <= pool_size/2 then
(1 - exp(-add_entropy/pool_size)) >= (add_entropy/pool_size)*0.7869...
... so we can approximate the exponential with
3/4*add_entropy/pool_size and still be on the
safe side by adding at most pool_size/2 at a time.
In order for the loop not to take arbitrary amounts of time if a bad
ioctl is received, terminate if we are within one bit of full. This
way the loop is guaranteed to terminate after no more than
log2(poolsize) iterations, no matter what the input value is. The
vast majority of the time the loop will be executed exactly once.
The piecewise linearization is very conservative, approaching 3/4 of
the usable input value for small inputs, however, our entropy
estimation is pretty weak at best, especially for small values; we
have no handle on correlation; and the Shannon entropy measure (Rényi
entropy of order 1) is not the correct one to use in the first place,
but rather the correct entropy measure is the min-entropy, the Rényi
entropy of infinite order.
As such, this conservatism seems more than justified.
This does introduce fractional bit values. I have left it to have 3
bits of fraction, so that with a pool of 2^12 bits the multiply in
credit_entropy_bits() can still fit into an int, as 2*(3+12) < 31. It
is definitely possible to allow for more fractional accounting, but
that multiply then would have to be turned into a 32*32 -> 64 multiply.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: DJ Johnston <dj.johnston@intel.com>
2013-09-11 11:16:17 +08:00
|
|
|
const struct poolinfo *poolinfo;
|
2005-04-17 06:20:36 +08:00
|
|
|
__u32 *pool;
|
|
|
|
const char *name;
|
|
|
|
struct entropy_store *pull;
|
2013-10-03 13:08:15 +08:00
|
|
|
struct work_struct push_work;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* read-write data: */
|
2013-09-23 03:14:32 +08:00
|
|
|
unsigned long last_pulled;
|
2008-04-29 16:03:01 +08:00
|
|
|
spinlock_t lock;
|
2013-09-22 07:42:41 +08:00
|
|
|
unsigned short add_ptr;
|
|
|
|
unsigned short input_rotate;
|
2009-01-07 06:42:55 +08:00
|
|
|
int entropy_count;
|
2012-07-02 19:52:16 +08:00
|
|
|
int entropy_total;
|
|
|
|
unsigned int initialized:1;
|
2013-09-22 07:42:41 +08:00
|
|
|
unsigned int last_data_init:1;
|
2010-05-20 17:55:01 +08:00
|
|
|
__u8 last_data[EXTRACT_SIZE];
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
static ssize_t extract_entropy(struct entropy_store *r, void *buf,
|
|
|
|
size_t nbytes, int min, int rsvd);
|
|
|
|
static ssize_t _extract_entropy(struct entropy_store *r, void *buf,
|
|
|
|
size_t nbytes, int fips);
|
|
|
|
|
|
|
|
static void crng_reseed(struct crng_state *crng, struct entropy_store *r);
|
2013-10-03 13:08:15 +08:00
|
|
|
static void push_to_pool(struct work_struct *work);
|
2016-06-21 02:42:34 +08:00
|
|
|
static __u32 input_pool_data[INPUT_POOL_WORDS] __latent_entropy;
|
|
|
|
static __u32 blocking_pool_data[OUTPUT_POOL_WORDS] __latent_entropy;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
static struct entropy_store input_pool = {
|
|
|
|
.poolinfo = &poolinfo_table[0],
|
|
|
|
.name = "input",
|
2011-07-18 03:25:03 +08:00
|
|
|
.lock = __SPIN_LOCK_UNLOCKED(input_pool.lock),
|
2005-04-17 06:20:36 +08:00
|
|
|
.pool = input_pool_data
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct entropy_store blocking_pool = {
|
|
|
|
.poolinfo = &poolinfo_table[1],
|
|
|
|
.name = "blocking",
|
|
|
|
.pull = &input_pool,
|
2011-07-18 03:25:03 +08:00
|
|
|
.lock = __SPIN_LOCK_UNLOCKED(blocking_pool.lock),
|
2013-10-03 13:08:15 +08:00
|
|
|
.pool = blocking_pool_data,
|
|
|
|
.push_work = __WORK_INITIALIZER(blocking_pool.push_work,
|
|
|
|
push_to_pool),
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2012-07-02 19:52:16 +08:00
|
|
|
static __u32 const twist_table[8] = {
|
|
|
|
0x00000000, 0x3b6e20c8, 0x76dc4190, 0x4db26158,
|
|
|
|
0xedb88320, 0xd6d6a3e8, 0x9b64c2b0, 0xa00ae278 };
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2008-04-29 16:03:05 +08:00
|
|
|
* This function adds bytes into the entropy "pool". It does not
|
2005-04-17 06:20:36 +08:00
|
|
|
* update the entropy estimate. The caller should call
|
2008-04-29 16:03:07 +08:00
|
|
|
* credit_entropy_bits if this is appropriate.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*/
|
2012-07-05 04:19:30 +08:00
|
|
|
static void _mix_pool_bytes(struct entropy_store *r, const void *in,
|
2014-06-11 11:09:20 +08:00
|
|
|
int nbytes)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2014-06-11 11:09:20 +08:00
|
|
|
unsigned long i, tap1, tap2, tap3, tap4, tap5;
|
2008-04-29 16:03:02 +08:00
|
|
|
int input_rotate;
|
2005-04-17 06:20:36 +08:00
|
|
|
int wordmask = r->poolinfo->poolwords - 1;
|
2008-04-29 16:03:05 +08:00
|
|
|
const char *bytes = in;
|
2008-04-29 16:03:03 +08:00
|
|
|
__u32 w;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
tap1 = r->poolinfo->tap1;
|
|
|
|
tap2 = r->poolinfo->tap2;
|
|
|
|
tap3 = r->poolinfo->tap3;
|
|
|
|
tap4 = r->poolinfo->tap4;
|
|
|
|
tap5 = r->poolinfo->tap5;
|
|
|
|
|
2014-06-11 10:46:37 +08:00
|
|
|
input_rotate = r->input_rotate;
|
|
|
|
i = r->add_ptr;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-04-29 16:03:05 +08:00
|
|
|
/* mix one byte at a time to simplify size handling and churn faster */
|
|
|
|
while (nbytes--) {
|
2013-09-22 07:42:41 +08:00
|
|
|
w = rol32(*bytes++, input_rotate);
|
2008-04-29 16:03:04 +08:00
|
|
|
i = (i - 1) & wordmask;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* XOR in the various taps */
|
2008-04-29 16:03:04 +08:00
|
|
|
w ^= r->pool[i];
|
2005-04-17 06:20:36 +08:00
|
|
|
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];
|
2008-04-29 16:03:04 +08:00
|
|
|
|
|
|
|
/* Mix the result back in with a twist */
|
2005-04-17 06:20:36 +08:00
|
|
|
r->pool[i] = (w >> 3) ^ twist_table[w & 7];
|
2008-04-29 16:03:02 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
2013-09-22 07:42:41 +08:00
|
|
|
input_rotate = (input_rotate + (i ? 7 : 14)) & 31;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2014-06-11 10:46:37 +08:00
|
|
|
r->input_rotate = input_rotate;
|
|
|
|
r->add_ptr = i;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2012-07-05 04:19:30 +08:00
|
|
|
static void __mix_pool_bytes(struct entropy_store *r, const void *in,
|
2014-06-11 11:09:20 +08:00
|
|
|
int nbytes)
|
2012-07-05 04:19:30 +08:00
|
|
|
{
|
|
|
|
trace_mix_pool_bytes_nolock(r->name, nbytes, _RET_IP_);
|
2014-06-11 11:09:20 +08:00
|
|
|
_mix_pool_bytes(r, in, nbytes);
|
2012-07-05 04:19:30 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void mix_pool_bytes(struct entropy_store *r, const void *in,
|
2014-06-11 11:09:20 +08:00
|
|
|
int nbytes)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2012-07-04 22:38:30 +08:00
|
|
|
unsigned long flags;
|
|
|
|
|
2012-07-05 04:19:30 +08:00
|
|
|
trace_mix_pool_bytes(r->name, nbytes, _RET_IP_);
|
2012-07-04 22:38:30 +08:00
|
|
|
spin_lock_irqsave(&r->lock, flags);
|
2014-06-11 11:09:20 +08:00
|
|
|
_mix_pool_bytes(r, in, nbytes);
|
2012-07-04 22:38:30 +08:00
|
|
|
spin_unlock_irqrestore(&r->lock, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2012-07-02 19:52:16 +08:00
|
|
|
struct fast_pool {
|
|
|
|
__u32 pool[4];
|
|
|
|
unsigned long last;
|
2014-06-16 04:59:24 +08:00
|
|
|
unsigned short reg_idx;
|
2014-06-14 15:06:57 +08:00
|
|
|
unsigned char count;
|
2012-07-02 19:52:16 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is a fast mixing routine used by the interrupt randomness
|
|
|
|
* collector. It's hardcoded for an 128 bit pool and assumes that any
|
|
|
|
* locks that might be needed are taken by the caller.
|
|
|
|
*/
|
2014-06-15 09:43:13 +08:00
|
|
|
static void fast_mix(struct fast_pool *f)
|
2012-07-02 19:52:16 +08:00
|
|
|
{
|
2014-06-15 09:43:13 +08:00
|
|
|
__u32 a = f->pool[0], b = f->pool[1];
|
|
|
|
__u32 c = f->pool[2], d = f->pool[3];
|
|
|
|
|
|
|
|
a += b; c += d;
|
2015-02-07 13:32:06 +08:00
|
|
|
b = rol32(b, 6); d = rol32(d, 27);
|
2014-06-15 09:43:13 +08:00
|
|
|
d ^= a; b ^= c;
|
|
|
|
|
|
|
|
a += b; c += d;
|
2015-02-07 13:32:06 +08:00
|
|
|
b = rol32(b, 16); d = rol32(d, 14);
|
2014-06-15 09:43:13 +08:00
|
|
|
d ^= a; b ^= c;
|
|
|
|
|
|
|
|
a += b; c += d;
|
2015-02-07 13:32:06 +08:00
|
|
|
b = rol32(b, 6); d = rol32(d, 27);
|
2014-06-15 09:43:13 +08:00
|
|
|
d ^= a; b ^= c;
|
|
|
|
|
|
|
|
a += b; c += d;
|
2015-02-07 13:32:06 +08:00
|
|
|
b = rol32(b, 16); d = rol32(d, 14);
|
2014-06-15 09:43:13 +08:00
|
|
|
d ^= a; b ^= c;
|
|
|
|
|
|
|
|
f->pool[0] = a; f->pool[1] = b;
|
|
|
|
f->pool[2] = c; f->pool[3] = d;
|
2013-09-23 03:24:02 +08:00
|
|
|
f->count++;
|
2012-07-02 19:52:16 +08:00
|
|
|
}
|
|
|
|
|
2015-06-09 18:19:39 +08:00
|
|
|
static void process_random_ready_list(void)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
struct random_ready_callback *rdy, *tmp;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&random_ready_list_lock, flags);
|
|
|
|
list_for_each_entry_safe(rdy, tmp, &random_ready_list, list) {
|
|
|
|
struct module *owner = rdy->owner;
|
|
|
|
|
|
|
|
list_del_init(&rdy->list);
|
|
|
|
rdy->func(rdy);
|
|
|
|
module_put(owner);
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&random_ready_list_lock, flags);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2013-09-11 11:16:17 +08:00
|
|
|
* Credit (or debit) the entropy store with n bits of entropy.
|
|
|
|
* Use credit_entropy_bits_safe() if the value comes from userspace
|
|
|
|
* or otherwise should be checked for extreme values.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2008-04-29 16:03:07 +08:00
|
|
|
static void credit_entropy_bits(struct entropy_store *r, int nbits)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2012-07-04 22:38:30 +08:00
|
|
|
int entropy_count, orig;
|
random: account for entropy loss due to overwrites
When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool. This means that unless the pool is
fully empty, we are currently *guaranteed* to overestimate the amount
of entropy in the pool!
Assuming Shannon entropy with zero correlations we end up with an
exponentally decaying value of new entropy added:
entropy <- entropy + (pool_size - entropy) *
(1 - exp(-add_entropy/pool_size))
However, calculations involving fractional exponentials are not
practical in the kernel, so apply a piecewise linearization:
For add_entropy <= pool_size/2 then
(1 - exp(-add_entropy/pool_size)) >= (add_entropy/pool_size)*0.7869...
... so we can approximate the exponential with
3/4*add_entropy/pool_size and still be on the
safe side by adding at most pool_size/2 at a time.
In order for the loop not to take arbitrary amounts of time if a bad
ioctl is received, terminate if we are within one bit of full. This
way the loop is guaranteed to terminate after no more than
log2(poolsize) iterations, no matter what the input value is. The
vast majority of the time the loop will be executed exactly once.
The piecewise linearization is very conservative, approaching 3/4 of
the usable input value for small inputs, however, our entropy
estimation is pretty weak at best, especially for small values; we
have no handle on correlation; and the Shannon entropy measure (Rényi
entropy of order 1) is not the correct one to use in the first place,
but rather the correct entropy measure is the min-entropy, the Rényi
entropy of infinite order.
As such, this conservatism seems more than justified.
This does introduce fractional bit values. I have left it to have 3
bits of fraction, so that with a pool of 2^12 bits the multiply in
credit_entropy_bits() can still fit into an int, as 2*(3+12) < 31. It
is definitely possible to allow for more fractional accounting, but
that multiply then would have to be turned into a 32*32 -> 64 multiply.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: DJ Johnston <dj.johnston@intel.com>
2013-09-11 11:16:17 +08:00
|
|
|
const int pool_size = r->poolinfo->poolfracbits;
|
|
|
|
int nfrac = nbits << ENTROPY_SHIFT;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-04-29 16:03:07 +08:00
|
|
|
if (!nbits)
|
|
|
|
return;
|
|
|
|
|
2012-07-04 22:38:30 +08:00
|
|
|
retry:
|
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24 05:07:29 +08:00
|
|
|
entropy_count = orig = READ_ONCE(r->entropy_count);
|
random: account for entropy loss due to overwrites
When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool. This means that unless the pool is
fully empty, we are currently *guaranteed* to overestimate the amount
of entropy in the pool!
Assuming Shannon entropy with zero correlations we end up with an
exponentally decaying value of new entropy added:
entropy <- entropy + (pool_size - entropy) *
(1 - exp(-add_entropy/pool_size))
However, calculations involving fractional exponentials are not
practical in the kernel, so apply a piecewise linearization:
For add_entropy <= pool_size/2 then
(1 - exp(-add_entropy/pool_size)) >= (add_entropy/pool_size)*0.7869...
... so we can approximate the exponential with
3/4*add_entropy/pool_size and still be on the
safe side by adding at most pool_size/2 at a time.
In order for the loop not to take arbitrary amounts of time if a bad
ioctl is received, terminate if we are within one bit of full. This
way the loop is guaranteed to terminate after no more than
log2(poolsize) iterations, no matter what the input value is. The
vast majority of the time the loop will be executed exactly once.
The piecewise linearization is very conservative, approaching 3/4 of
the usable input value for small inputs, however, our entropy
estimation is pretty weak at best, especially for small values; we
have no handle on correlation; and the Shannon entropy measure (Rényi
entropy of order 1) is not the correct one to use in the first place,
but rather the correct entropy measure is the min-entropy, the Rényi
entropy of infinite order.
As such, this conservatism seems more than justified.
This does introduce fractional bit values. I have left it to have 3
bits of fraction, so that with a pool of 2^12 bits the multiply in
credit_entropy_bits() can still fit into an int, as 2*(3+12) < 31. It
is definitely possible to allow for more fractional accounting, but
that multiply then would have to be turned into a 32*32 -> 64 multiply.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: DJ Johnston <dj.johnston@intel.com>
2013-09-11 11:16:17 +08:00
|
|
|
if (nfrac < 0) {
|
|
|
|
/* Debit */
|
|
|
|
entropy_count += nfrac;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Credit: we have to account for the possibility of
|
|
|
|
* overwriting already present entropy. Even in the
|
|
|
|
* ideal case of pure Shannon entropy, new contributions
|
|
|
|
* approach the full value asymptotically:
|
|
|
|
*
|
|
|
|
* entropy <- entropy + (pool_size - entropy) *
|
|
|
|
* (1 - exp(-add_entropy/pool_size))
|
|
|
|
*
|
|
|
|
* For add_entropy <= pool_size/2 then
|
|
|
|
* (1 - exp(-add_entropy/pool_size)) >=
|
|
|
|
* (add_entropy/pool_size)*0.7869...
|
|
|
|
* so we can approximate the exponential with
|
|
|
|
* 3/4*add_entropy/pool_size and still be on the
|
|
|
|
* safe side by adding at most pool_size/2 at a time.
|
|
|
|
*
|
|
|
|
* The use of pool_size-2 in the while statement is to
|
|
|
|
* prevent rounding artifacts from making the loop
|
|
|
|
* arbitrarily long; this limits the loop to log2(pool_size)*2
|
|
|
|
* turns no matter how large nbits is.
|
|
|
|
*/
|
|
|
|
int pnfrac = nfrac;
|
|
|
|
const int s = r->poolinfo->poolbitshift + ENTROPY_SHIFT + 2;
|
|
|
|
/* The +2 corresponds to the /4 in the denominator */
|
|
|
|
|
|
|
|
do {
|
|
|
|
unsigned int anfrac = min(pnfrac, pool_size/2);
|
|
|
|
unsigned int add =
|
|
|
|
((pool_size - entropy_count)*anfrac*3) >> s;
|
|
|
|
|
|
|
|
entropy_count += add;
|
|
|
|
pnfrac -= anfrac;
|
|
|
|
} while (unlikely(entropy_count < pool_size-2 && pnfrac));
|
|
|
|
}
|
2012-07-05 04:19:30 +08:00
|
|
|
|
2014-07-19 05:26:41 +08:00
|
|
|
if (unlikely(entropy_count < 0)) {
|
2013-10-04 00:02:37 +08:00
|
|
|
pr_warn("random: negative entropy/overflow: pool %s count %d\n",
|
|
|
|
r->name, entropy_count);
|
|
|
|
WARN_ON(1);
|
2008-09-03 05:36:14 +08:00
|
|
|
entropy_count = 0;
|
random: account for entropy loss due to overwrites
When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool. This means that unless the pool is
fully empty, we are currently *guaranteed* to overestimate the amount
of entropy in the pool!
Assuming Shannon entropy with zero correlations we end up with an
exponentally decaying value of new entropy added:
entropy <- entropy + (pool_size - entropy) *
(1 - exp(-add_entropy/pool_size))
However, calculations involving fractional exponentials are not
practical in the kernel, so apply a piecewise linearization:
For add_entropy <= pool_size/2 then
(1 - exp(-add_entropy/pool_size)) >= (add_entropy/pool_size)*0.7869...
... so we can approximate the exponential with
3/4*add_entropy/pool_size and still be on the
safe side by adding at most pool_size/2 at a time.
In order for the loop not to take arbitrary amounts of time if a bad
ioctl is received, terminate if we are within one bit of full. This
way the loop is guaranteed to terminate after no more than
log2(poolsize) iterations, no matter what the input value is. The
vast majority of the time the loop will be executed exactly once.
The piecewise linearization is very conservative, approaching 3/4 of
the usable input value for small inputs, however, our entropy
estimation is pretty weak at best, especially for small values; we
have no handle on correlation; and the Shannon entropy measure (Rényi
entropy of order 1) is not the correct one to use in the first place,
but rather the correct entropy measure is the min-entropy, the Rényi
entropy of infinite order.
As such, this conservatism seems more than justified.
This does introduce fractional bit values. I have left it to have 3
bits of fraction, so that with a pool of 2^12 bits the multiply in
credit_entropy_bits() can still fit into an int, as 2*(3+12) < 31. It
is definitely possible to allow for more fractional accounting, but
that multiply then would have to be turned into a 32*32 -> 64 multiply.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: DJ Johnston <dj.johnston@intel.com>
2013-09-11 11:16:17 +08:00
|
|
|
} else if (entropy_count > pool_size)
|
|
|
|
entropy_count = pool_size;
|
2012-07-04 22:38:30 +08:00
|
|
|
if (cmpxchg(&r->entropy_count, orig, entropy_count) != orig)
|
|
|
|
goto retry;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-10-03 13:08:15 +08:00
|
|
|
r->entropy_total += nbits;
|
The /dev/random changes for 3.13 including a number of improvements in
the following areas: performance, avoiding waste of entropy, better
tracking of entropy estimates, support for non-x86 platforms that have
a register which can't be used for fine-grained timekeeping, but which
might be good enough for the random driver.
Also add some printk's so that we can see how quickly /dev/urandom can
get initialized, and when programs try to use /dev/urandom before it
is fully initialized (since this could be a security issue). This
shouldn't be an issue on x86 desktop/laptops --- a test on my Lenovo
T430s laptop shows that /dev/urandom is getting fully initialized
approximately two seconds before the root file system is mounted
read/write --- this may be an issue with ARM and MIPS embedded/mobile
systems, though. These printk's will be a useful canary before
potentially adding a future change to start blocking processes which
try to read from /dev/urandom before it is initialized, which is
something FreeBSD does already for security reasons, and which
security folks have been agitating for Linux to also adopt.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABCAAGBQJShC4MAAoJENNvdpvBGATwC0QQAMujsIxTZnsHwQrbb5eJf1kD
74TwQyEfWw5qnGQrc8JOoAbe1MG7C4QlfHxRsWxvCD8G+Mft4Q5ZgZOt0/ecAGD6
Tid58EaZGSfK9+YE6jgvJFekQADCREdPSxBASJ3cECT6dXXBX9IqR9gbAK02mM+w
QZdbgWBMsPJZiHSsCNeRbZ9oIiPdcNDsMJwzJhirPUeAnKCaX3z+LWc3XcMw7wYi
q5cSl0ENZd6QsBKs37A1ol5BtLEsoot2t3HKdnpOBsDQKSJ712KduwN5jUfs6h9D
0fqmVHwfKsge+D8/3NgBKz+yWLQnGkuB4Ibo+09BZXwH3rYU1/gKm0iLNi0yQ5fV
73bn4pqF6cZdDNgj0Ic+MyYAW+S/NOQ6TcF/3eSAPW6z/wHZOfZ2njCh1GEHBOKI
6iZZu+Ek7QyFJ/z5Fr1bXFJR7V99r7hRD3gwMCMZ/mjhloB2cyD0a2A9kFP85ykI
I4tFEnq0FpX/K60ag4hiLnqVx/TsmbdMoz+8OpQckHgQJrZMuRRf1d+T4au47Y6K
uXGLpSuvkALYW2koo2OoO2d873N/89fqFL8lI8Iy0YlgAxxxm++gl1Mql/E1wPOa
5jB0lW/jex/CquE7meTgRlM/fTU/HVbe3608ZNUYBJUHS9K/PaSnCCu2ya8/TsSW
xeVS/vMnNvtGerdEIyKm
=wla0
-----END PGP SIGNATURE-----
Merge tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random
Pull /dev/random changes from Ted Ts'o:
"The /dev/random changes for 3.13 including a number of improvements in
the following areas: performance, avoiding waste of entropy, better
tracking of entropy estimates, support for non-x86 platforms that have
a register which can't be used for fine-grained timekeeping, but which
might be good enough for the random driver.
Also add some printk's so that we can see how quickly /dev/urandom can
get initialized, and when programs try to use /dev/urandom before it
is fully initialized (since this could be a security issue). This
shouldn't be an issue on x86 desktop/laptops --- a test on my Lenovo
T430s laptop shows that /dev/urandom is getting fully initialized
approximately two seconds before the root file system is mounted
read/write --- this may be an issue with ARM and MIPS embedded/mobile
systems, though. These printk's will be a useful canary before
potentially adding a future change to start blocking processes which
try to read from /dev/urandom before it is initialized, which is
something FreeBSD does already for security reasons, and which
security folks have been agitating for Linux to also adopt"
* tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
random: add debugging code to detect early use of get_random_bytes()
random: initialize the last_time field in struct timer_rand_state
random: don't zap entropy count in rand_initialize()
random: printk notifications for urandom pool initialization
random: make add_timer_randomness() fill the nonblocking pool first
random: convert DEBUG_ENT to tracepoints
random: push extra entropy to the output pools
random: drop trickle mode
random: adjust the generator polynomials in the mixing function slightly
random: speed up the fast_mix function by a factor of four
random: cap the rate which the /dev/urandom pool gets reseeded
random: optimize the entropy_store structure
random: optimize spinlock use in add_device_randomness()
random: fix the tracepoint for get_random_bytes(_arch)
random: account for entropy loss due to overwrites
random: allow fractional bits to be tracked
random: statically compute poolbitshift, poolbytes, poolbits
random: mix in architectural randomness earlier in extract_buf()
2013-11-17 02:19:15 +08:00
|
|
|
if (!r->initialized && r->entropy_total > 128) {
|
|
|
|
r->initialized = 1;
|
|
|
|
r->entropy_total = 0;
|
2012-07-02 19:52:16 +08:00
|
|
|
}
|
|
|
|
|
2013-09-11 11:16:17 +08:00
|
|
|
trace_credit_entropy_bits(r->name, nbits,
|
|
|
|
entropy_count >> ENTROPY_SHIFT,
|
2012-07-05 04:19:30 +08:00
|
|
|
r->entropy_total, _RET_IP_);
|
|
|
|
|
2013-10-03 13:08:15 +08:00
|
|
|
if (r == &input_pool) {
|
2013-12-07 22:49:55 +08:00
|
|
|
int entropy_bits = entropy_count >> ENTROPY_SHIFT;
|
2013-10-03 13:08:15 +08:00
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
if (crng_init < 2 && entropy_bits >= 128) {
|
|
|
|
crng_reseed(&primary_crng, r);
|
|
|
|
entropy_bits = r->entropy_count >> ENTROPY_SHIFT;
|
|
|
|
}
|
|
|
|
|
2013-10-03 13:08:15 +08:00
|
|
|
/* should we wake readers? */
|
2018-03-01 05:43:28 +08:00
|
|
|
if (entropy_bits >= random_read_wakeup_bits &&
|
|
|
|
wq_has_sleeper(&random_read_wait)) {
|
2013-10-03 13:08:15 +08:00
|
|
|
wake_up_interruptible(&random_read_wait);
|
|
|
|
kill_fasync(&fasync, SIGIO, POLL_IN);
|
|
|
|
}
|
|
|
|
/* If the input pool is getting full, send some
|
2016-06-13 06:13:36 +08:00
|
|
|
* entropy to the blocking pool until it is 75% full.
|
2013-10-03 13:08:15 +08:00
|
|
|
*/
|
2013-12-07 10:28:03 +08:00
|
|
|
if (entropy_bits > random_write_wakeup_bits &&
|
2013-10-03 13:08:15 +08:00
|
|
|
r->initialized &&
|
2013-12-07 10:28:03 +08:00
|
|
|
r->entropy_total >= 2*random_read_wakeup_bits) {
|
2013-10-03 13:08:15 +08:00
|
|
|
struct entropy_store *other = &blocking_pool;
|
|
|
|
|
|
|
|
if (other->entropy_count <=
|
2016-06-13 06:13:36 +08:00
|
|
|
3 * other->poolinfo->poolfracbits / 4) {
|
|
|
|
schedule_work(&other->push_work);
|
2013-10-03 13:08:15 +08:00
|
|
|
r->entropy_total = 0;
|
|
|
|
}
|
|
|
|
}
|
random: add async notification support to /dev/random
Add async notification support to /dev/random.
A little test case is below. Without this patch, you get:
$ ./async-random
Drained the pool
Found more randomness
With it, you get:
$ ./async-random
Drained the pool
SIGIO
Found more randomness
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <errno.h>
#include <fcntl.h>
static void handler(int sig)
{
printf("SIGIO\n");
}
int main(int argc, char **argv)
{
int fd, n, err, flags;
if(signal(SIGIO, handler) < 0){
perror("setting SIGIO handler");
exit(1);
}
fd = open("/dev/random", O_RDONLY);
if(fd < 0){
perror("open");
exit(1);
}
flags = fcntl(fd, F_GETFL);
if (flags < 0){
perror("getting flags");
exit(1);
}
flags |= O_NONBLOCK;
if (fcntl(fd, F_SETFL, flags) < 0){
perror("setting flags");
exit(1);
}
while((err = read(fd, &n, sizeof(n))) > 0) ;
if(err == 0){
printf("random returned 0\n");
exit(1);
}
else if(errno != EAGAIN){
perror("read");
exit(1);
}
flags |= O_ASYNC;
if (fcntl(fd, F_SETFL, flags) < 0){
perror("setting flags");
exit(1);
}
if (fcntl(fd, F_SETOWN, getpid()) < 0) {
perror("Setting SIGIO");
exit(1);
}
printf("Drained the pool\n");
read(fd, &n, sizeof(n));
printf("Found more randomness\n");
return(0);
}
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Matt Mackall <mpm@selenic.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-29 16:03:08 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2016-07-04 05:01:26 +08:00
|
|
|
static int credit_entropy_bits_safe(struct entropy_store *r, int nbits)
|
2013-09-11 11:16:17 +08:00
|
|
|
{
|
2017-02-26 06:21:33 +08:00
|
|
|
const int nbits_max = r->poolinfo->poolwords * 32;
|
2013-09-11 11:16:17 +08:00
|
|
|
|
2016-07-04 05:01:26 +08:00
|
|
|
if (nbits < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2013-09-11 11:16:17 +08:00
|
|
|
/* Cap the value to avoid overflows */
|
|
|
|
nbits = min(nbits, nbits_max);
|
|
|
|
|
|
|
|
credit_entropy_bits(r, nbits);
|
2016-07-04 05:01:26 +08:00
|
|
|
return 0;
|
2013-09-11 11:16:17 +08:00
|
|
|
}
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
/*********************************************************************
|
|
|
|
*
|
|
|
|
* CRNG using CHACHA20
|
|
|
|
*
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
#define CRNG_RESEED_INTERVAL (300*HZ)
|
|
|
|
|
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(crng_init_wait);
|
|
|
|
|
2016-05-02 14:04:41 +08:00
|
|
|
#ifdef CONFIG_NUMA
|
|
|
|
/*
|
|
|
|
* Hack to deal with crazy userspace progams when they are all trying
|
|
|
|
* to access /dev/urandom in parallel. The programs are almost
|
|
|
|
* certainly doing something terribly wrong, but we'll work around
|
|
|
|
* their brain damage.
|
|
|
|
*/
|
|
|
|
static struct crng_state **crng_node_pool __read_mostly;
|
|
|
|
#endif
|
|
|
|
|
random: invalidate batched entropy after crng init
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
2017-06-08 07:45:31 +08:00
|
|
|
static void invalidate_batched_entropy(void);
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
static void crng_initialize(struct crng_state *crng)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
unsigned long rv;
|
|
|
|
|
|
|
|
memcpy(&crng->state[0], "expand 32-byte k", 16);
|
|
|
|
if (crng == &primary_crng)
|
|
|
|
_extract_entropy(&input_pool, &crng->state[4],
|
|
|
|
sizeof(__u32) * 12, 0);
|
|
|
|
else
|
2017-06-08 16:16:59 +08:00
|
|
|
_get_random_bytes(&crng->state[4], sizeof(__u32) * 12);
|
2016-06-13 06:13:36 +08:00
|
|
|
for (i = 4; i < 16; i++) {
|
|
|
|
if (!arch_get_random_seed_long(&rv) &&
|
|
|
|
!arch_get_random_long(&rv))
|
|
|
|
rv = random_get_entropy();
|
|
|
|
crng->state[i] ^= rv;
|
|
|
|
}
|
|
|
|
crng->init_time = jiffies - CRNG_RESEED_INTERVAL - 1;
|
|
|
|
}
|
|
|
|
|
2018-04-12 03:23:56 +08:00
|
|
|
#ifdef CONFIG_NUMA
|
2018-04-24 06:51:28 +08:00
|
|
|
static void do_numa_crng_init(struct work_struct *work)
|
2018-04-12 03:23:56 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct crng_state *crng;
|
|
|
|
struct crng_state **pool;
|
|
|
|
|
|
|
|
pool = kcalloc(nr_node_ids, sizeof(*pool), GFP_KERNEL|__GFP_NOFAIL);
|
|
|
|
for_each_online_node(i) {
|
|
|
|
crng = kmalloc_node(sizeof(struct crng_state),
|
|
|
|
GFP_KERNEL | __GFP_NOFAIL, i);
|
|
|
|
spin_lock_init(&crng->lock);
|
|
|
|
crng_initialize(crng);
|
|
|
|
pool[i] = crng;
|
|
|
|
}
|
|
|
|
mb();
|
|
|
|
if (cmpxchg(&crng_node_pool, NULL, pool)) {
|
|
|
|
for_each_node(i)
|
|
|
|
kfree(pool[i]);
|
|
|
|
kfree(pool);
|
|
|
|
}
|
|
|
|
}
|
2018-04-24 06:51:28 +08:00
|
|
|
|
|
|
|
static DECLARE_WORK(numa_crng_init_work, do_numa_crng_init);
|
|
|
|
|
|
|
|
static void numa_crng_init(void)
|
|
|
|
{
|
|
|
|
schedule_work(&numa_crng_init_work);
|
|
|
|
}
|
2018-04-12 03:23:56 +08:00
|
|
|
#else
|
|
|
|
static void numa_crng_init(void) {}
|
|
|
|
#endif
|
|
|
|
|
2018-04-12 02:58:27 +08:00
|
|
|
/*
|
|
|
|
* crng_fast_load() can be called by code in the interrupt service
|
|
|
|
* path. So we can't afford to dilly-dally.
|
|
|
|
*/
|
2016-06-13 06:13:36 +08:00
|
|
|
static int crng_fast_load(const char *cp, size_t len)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
char *p;
|
|
|
|
|
|
|
|
if (!spin_trylock_irqsave(&primary_crng.lock, flags))
|
|
|
|
return 0;
|
2018-04-12 01:27:52 +08:00
|
|
|
if (crng_init != 0) {
|
2016-06-13 06:13:36 +08:00
|
|
|
spin_unlock_irqrestore(&primary_crng.lock, flags);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
p = (unsigned char *) &primary_crng.state[4];
|
|
|
|
while (len > 0 && crng_init_cnt < CRNG_INIT_CNT_THRESH) {
|
|
|
|
p[crng_init_cnt % CHACHA20_KEY_SIZE] ^= *cp;
|
|
|
|
cp++; crng_init_cnt++; len--;
|
|
|
|
}
|
2017-06-15 06:45:26 +08:00
|
|
|
spin_unlock_irqrestore(&primary_crng.lock, flags);
|
2016-06-13 06:13:36 +08:00
|
|
|
if (crng_init_cnt >= CRNG_INIT_CNT_THRESH) {
|
random: invalidate batched entropy after crng init
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
2017-06-08 07:45:31 +08:00
|
|
|
invalidate_batched_entropy();
|
2016-06-13 06:13:36 +08:00
|
|
|
crng_init = 1;
|
|
|
|
wake_up_interruptible(&crng_init_wait);
|
|
|
|
pr_notice("random: fast init done\n");
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2018-04-12 02:58:27 +08:00
|
|
|
/*
|
|
|
|
* crng_slow_load() is called by add_device_randomness, which has two
|
|
|
|
* attributes. (1) We can't trust the buffer passed to it is
|
|
|
|
* guaranteed to be unpredictable (so it might not have any entropy at
|
|
|
|
* all), and (2) it doesn't have the performance constraints of
|
|
|
|
* crng_fast_load().
|
|
|
|
*
|
|
|
|
* So we do something more comprehensive which is guaranteed to touch
|
|
|
|
* all of the primary_crng's state, and which uses a LFSR with a
|
|
|
|
* period of 255 as part of the mixing algorithm. Finally, we do
|
|
|
|
* *not* advance crng_init_cnt since buffer we may get may be something
|
|
|
|
* like a fixed DMI table (for example), which might very well be
|
|
|
|
* unique to the machine, but is otherwise unvarying.
|
|
|
|
*/
|
|
|
|
static int crng_slow_load(const char *cp, size_t len)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
static unsigned char lfsr = 1;
|
|
|
|
unsigned char tmp;
|
|
|
|
unsigned i, max = CHACHA20_KEY_SIZE;
|
|
|
|
const char * src_buf = cp;
|
|
|
|
char * dest_buf = (char *) &primary_crng.state[4];
|
|
|
|
|
|
|
|
if (!spin_trylock_irqsave(&primary_crng.lock, flags))
|
|
|
|
return 0;
|
|
|
|
if (crng_init != 0) {
|
|
|
|
spin_unlock_irqrestore(&primary_crng.lock, flags);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (len > max)
|
|
|
|
max = len;
|
|
|
|
|
|
|
|
for (i = 0; i < max ; i++) {
|
|
|
|
tmp = lfsr;
|
|
|
|
lfsr >>= 1;
|
|
|
|
if (tmp & 1)
|
|
|
|
lfsr ^= 0xE1;
|
|
|
|
tmp = dest_buf[i % CHACHA20_KEY_SIZE];
|
|
|
|
dest_buf[i % CHACHA20_KEY_SIZE] ^= src_buf[i % len] ^ lfsr;
|
|
|
|
lfsr += (tmp << 3) | (tmp >> 5);
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&primary_crng.lock, flags);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
int i, num;
|
|
|
|
union {
|
2017-11-23 03:51:39 +08:00
|
|
|
__u32 block[CHACHA20_BLOCK_WORDS];
|
2016-06-13 06:13:36 +08:00
|
|
|
__u32 key[8];
|
|
|
|
} buf;
|
|
|
|
|
|
|
|
if (r) {
|
|
|
|
num = extract_entropy(r, &buf, 32, 16, 0);
|
|
|
|
if (num == 0)
|
|
|
|
return;
|
2016-05-05 01:29:18 +08:00
|
|
|
} else {
|
2016-05-02 14:04:41 +08:00
|
|
|
_extract_crng(&primary_crng, buf.block);
|
2016-05-05 01:29:18 +08:00
|
|
|
_crng_backtrack_protect(&primary_crng, buf.block,
|
|
|
|
CHACHA20_KEY_SIZE);
|
|
|
|
}
|
2018-04-12 12:50:45 +08:00
|
|
|
spin_lock_irqsave(&crng->lock, flags);
|
2016-06-13 06:13:36 +08:00
|
|
|
for (i = 0; i < 8; i++) {
|
|
|
|
unsigned long rv;
|
|
|
|
if (!arch_get_random_seed_long(&rv) &&
|
|
|
|
!arch_get_random_long(&rv))
|
|
|
|
rv = random_get_entropy();
|
|
|
|
crng->state[i+4] ^= buf.key[i] ^ rv;
|
|
|
|
}
|
|
|
|
memzero_explicit(&buf, sizeof(buf));
|
|
|
|
crng->init_time = jiffies;
|
2018-04-12 12:50:45 +08:00
|
|
|
spin_unlock_irqrestore(&crng->lock, flags);
|
2016-06-13 06:13:36 +08:00
|
|
|
if (crng == &primary_crng && crng_init < 2) {
|
random: invalidate batched entropy after crng init
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
2017-06-08 07:45:31 +08:00
|
|
|
invalidate_batched_entropy();
|
2018-04-12 03:23:56 +08:00
|
|
|
numa_crng_init();
|
2016-06-13 06:13:36 +08:00
|
|
|
crng_init = 2;
|
|
|
|
process_random_ready_list();
|
|
|
|
wake_up_interruptible(&crng_init_wait);
|
|
|
|
pr_notice("random: crng init done\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-02 14:04:41 +08:00
|
|
|
static void _extract_crng(struct crng_state *crng,
|
2017-11-23 03:51:39 +08:00
|
|
|
__u32 out[CHACHA20_BLOCK_WORDS])
|
2016-06-13 06:13:36 +08:00
|
|
|
{
|
|
|
|
unsigned long v, flags;
|
|
|
|
|
2018-04-12 01:27:52 +08:00
|
|
|
if (crng_ready() &&
|
2018-04-12 04:32:17 +08:00
|
|
|
(time_after(crng_global_init_time, crng->init_time) ||
|
|
|
|
time_after(jiffies, crng->init_time + CRNG_RESEED_INTERVAL)))
|
2016-05-02 14:04:41 +08:00
|
|
|
crng_reseed(crng, crng == &primary_crng ? &input_pool : NULL);
|
2016-06-13 06:13:36 +08:00
|
|
|
spin_lock_irqsave(&crng->lock, flags);
|
|
|
|
if (arch_get_random_long(&v))
|
|
|
|
crng->state[14] ^= v;
|
|
|
|
chacha20_block(&crng->state[0], out);
|
|
|
|
if (crng->state[12] == 0)
|
|
|
|
crng->state[13]++;
|
|
|
|
spin_unlock_irqrestore(&crng->lock, flags);
|
|
|
|
}
|
|
|
|
|
2017-11-23 03:51:39 +08:00
|
|
|
static void extract_crng(__u32 out[CHACHA20_BLOCK_WORDS])
|
2016-05-02 14:04:41 +08:00
|
|
|
{
|
|
|
|
struct crng_state *crng = NULL;
|
|
|
|
|
|
|
|
#ifdef CONFIG_NUMA
|
|
|
|
if (crng_node_pool)
|
|
|
|
crng = crng_node_pool[numa_node_id()];
|
|
|
|
if (crng == NULL)
|
|
|
|
#endif
|
|
|
|
crng = &primary_crng;
|
|
|
|
_extract_crng(crng, out);
|
|
|
|
}
|
|
|
|
|
2016-05-05 01:29:18 +08:00
|
|
|
/*
|
|
|
|
* Use the leftover bytes from the CRNG block output (if there is
|
|
|
|
* enough) to mutate the CRNG key to provide backtracking protection.
|
|
|
|
*/
|
|
|
|
static void _crng_backtrack_protect(struct crng_state *crng,
|
2017-11-23 03:51:39 +08:00
|
|
|
__u32 tmp[CHACHA20_BLOCK_WORDS], int used)
|
2016-05-05 01:29:18 +08:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
__u32 *s, *d;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
used = round_up(used, sizeof(__u32));
|
|
|
|
if (used + CHACHA20_KEY_SIZE > CHACHA20_BLOCK_SIZE) {
|
|
|
|
extract_crng(tmp);
|
|
|
|
used = 0;
|
|
|
|
}
|
|
|
|
spin_lock_irqsave(&crng->lock, flags);
|
2017-11-23 03:51:39 +08:00
|
|
|
s = &tmp[used / sizeof(__u32)];
|
2016-05-05 01:29:18 +08:00
|
|
|
d = &crng->state[4];
|
|
|
|
for (i=0; i < 8; i++)
|
|
|
|
*d++ ^= *s++;
|
|
|
|
spin_unlock_irqrestore(&crng->lock, flags);
|
|
|
|
}
|
|
|
|
|
2017-11-23 03:51:39 +08:00
|
|
|
static void crng_backtrack_protect(__u32 tmp[CHACHA20_BLOCK_WORDS], int used)
|
2016-05-05 01:29:18 +08:00
|
|
|
{
|
|
|
|
struct crng_state *crng = NULL;
|
|
|
|
|
|
|
|
#ifdef CONFIG_NUMA
|
|
|
|
if (crng_node_pool)
|
|
|
|
crng = crng_node_pool[numa_node_id()];
|
|
|
|
if (crng == NULL)
|
|
|
|
#endif
|
|
|
|
crng = &primary_crng;
|
|
|
|
_crng_backtrack_protect(crng, tmp, used);
|
|
|
|
}
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
static ssize_t extract_crng_user(void __user *buf, size_t nbytes)
|
|
|
|
{
|
2016-05-05 01:29:18 +08:00
|
|
|
ssize_t ret = 0, i = CHACHA20_BLOCK_SIZE;
|
2017-11-23 03:51:39 +08:00
|
|
|
__u32 tmp[CHACHA20_BLOCK_WORDS];
|
2016-06-13 06:13:36 +08:00
|
|
|
int large_request = (nbytes > 256);
|
|
|
|
|
|
|
|
while (nbytes) {
|
|
|
|
if (large_request && need_resched()) {
|
|
|
|
if (signal_pending(current)) {
|
|
|
|
if (ret == 0)
|
|
|
|
ret = -ERESTARTSYS;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
schedule();
|
|
|
|
}
|
|
|
|
|
|
|
|
extract_crng(tmp);
|
|
|
|
i = min_t(int, nbytes, CHACHA20_BLOCK_SIZE);
|
|
|
|
if (copy_to_user(buf, tmp, i)) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
nbytes -= i;
|
|
|
|
buf += i;
|
|
|
|
ret += i;
|
|
|
|
}
|
2016-05-05 01:29:18 +08:00
|
|
|
crng_backtrack_protect(tmp, i);
|
2016-06-13 06:13:36 +08:00
|
|
|
|
|
|
|
/* Wipe data just written to memory */
|
|
|
|
memzero_explicit(tmp, sizeof(tmp));
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*********************************************************************
|
|
|
|
*
|
|
|
|
* Entropy input management
|
|
|
|
*
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
/* There is one of these per entropy source */
|
|
|
|
struct timer_rand_state {
|
|
|
|
cycles_t last_time;
|
2008-04-29 16:02:55 +08:00
|
|
|
long last_delta, last_delta2;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2013-11-04 05:40:53 +08:00
|
|
|
#define INIT_TIMER_RAND_STATE { INITIAL_JIFFIES, };
|
|
|
|
|
2012-07-04 23:16:01 +08:00
|
|
|
/*
|
2016-06-13 06:13:36 +08:00
|
|
|
* Add device- or boot-specific data to the input pool to help
|
|
|
|
* initialize it.
|
2012-07-04 23:16:01 +08:00
|
|
|
*
|
2016-06-13 06:13:36 +08:00
|
|
|
* None of this adds any entropy; it is meant to avoid the problem of
|
|
|
|
* the entropy pool having similar initial state across largely
|
|
|
|
* identical devices.
|
2012-07-04 23:16:01 +08:00
|
|
|
*/
|
|
|
|
void add_device_randomness(const void *buf, unsigned int size)
|
|
|
|
{
|
2013-09-22 01:58:22 +08:00
|
|
|
unsigned long time = random_get_entropy() ^ jiffies;
|
2013-09-13 02:27:22 +08:00
|
|
|
unsigned long flags;
|
2012-07-04 23:16:01 +08:00
|
|
|
|
2018-04-12 02:58:27 +08:00
|
|
|
if (!crng_ready() && size)
|
|
|
|
crng_slow_load(buf, size);
|
2017-07-13 05:34:04 +08:00
|
|
|
|
2013-09-13 02:10:25 +08:00
|
|
|
trace_add_device_randomness(size, _RET_IP_);
|
2013-09-13 02:27:22 +08:00
|
|
|
spin_lock_irqsave(&input_pool.lock, flags);
|
2014-06-11 11:09:20 +08:00
|
|
|
_mix_pool_bytes(&input_pool, buf, size);
|
|
|
|
_mix_pool_bytes(&input_pool, &time, sizeof(time));
|
2013-09-13 02:27:22 +08:00
|
|
|
spin_unlock_irqrestore(&input_pool.lock, flags);
|
2012-07-04 23:16:01 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(add_device_randomness);
|
|
|
|
|
2013-11-04 05:40:53 +08:00
|
|
|
static struct timer_rand_state input_timer_state = INIT_TIMER_RAND_STATE;
|
2008-08-20 11:50:08 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* This function adds entropy to the entropy "pool" by using timing
|
|
|
|
* delays. It uses the timer_rand_state structure to make an estimate
|
|
|
|
* of how many bits of entropy this call has added to the pool.
|
|
|
|
*
|
|
|
|
* The number "num" is also added to the pool - it should somehow describe
|
|
|
|
* the type of event which just happened. This is currently 0-255 for
|
|
|
|
* keyboard scan codes, and 256 upwards for interrupts.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static void add_timer_randomness(struct timer_rand_state *state, unsigned num)
|
|
|
|
{
|
2013-11-03 12:15:05 +08:00
|
|
|
struct entropy_store *r;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct {
|
|
|
|
long jiffies;
|
2011-12-23 03:36:22 +08:00
|
|
|
unsigned cycles;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned num;
|
|
|
|
} sample;
|
|
|
|
long delta, delta2, delta3;
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
|
|
|
|
sample.jiffies = jiffies;
|
2013-09-22 01:58:22 +08:00
|
|
|
sample.cycles = random_get_entropy();
|
2005-04-17 06:20:36 +08:00
|
|
|
sample.num = num;
|
2016-06-13 06:13:36 +08:00
|
|
|
r = &input_pool;
|
2014-06-11 11:09:20 +08:00
|
|
|
mix_pool_bytes(r, &sample, sizeof(sample));
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate number of bits of randomness we probably added.
|
|
|
|
* We take into account the first, second and third-order deltas
|
|
|
|
* in order to make our estimate.
|
|
|
|
*/
|
2018-03-01 07:22:47 +08:00
|
|
|
delta = sample.jiffies - state->last_time;
|
|
|
|
state->last_time = sample.jiffies;
|
|
|
|
|
|
|
|
delta2 = delta - state->last_delta;
|
|
|
|
state->last_delta = delta;
|
|
|
|
|
|
|
|
delta3 = delta2 - state->last_delta2;
|
|
|
|
state->last_delta2 = delta2;
|
|
|
|
|
|
|
|
if (delta < 0)
|
|
|
|
delta = -delta;
|
|
|
|
if (delta2 < 0)
|
|
|
|
delta2 = -delta2;
|
|
|
|
if (delta3 < 0)
|
|
|
|
delta3 = -delta3;
|
|
|
|
if (delta > delta2)
|
|
|
|
delta = delta2;
|
|
|
|
if (delta > delta3)
|
|
|
|
delta = delta3;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-03-01 07:22:47 +08:00
|
|
|
/*
|
|
|
|
* delta is now minimum absolute delta.
|
|
|
|
* Round down by 1 bit on general principles,
|
|
|
|
* and limit entropy entimate to 12 bits.
|
|
|
|
*/
|
|
|
|
credit_entropy_bits(r, min_t(int, fls(delta>>1), 11));
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
2006-01-12 04:17:38 +08:00
|
|
|
void add_input_randomness(unsigned int type, unsigned int code,
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned int value)
|
|
|
|
{
|
|
|
|
static unsigned char last_value;
|
|
|
|
|
|
|
|
/* ignore autorepeat and the like */
|
|
|
|
if (value == last_value)
|
|
|
|
return;
|
|
|
|
|
|
|
|
last_value = value;
|
|
|
|
add_timer_randomness(&input_timer_state,
|
|
|
|
(type << 4) ^ code ^ (code >> 4) ^ value);
|
2013-10-04 00:02:37 +08:00
|
|
|
trace_add_input_randomness(ENTROPY_BITS(&input_pool));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2006-10-11 13:43:58 +08:00
|
|
|
EXPORT_SYMBOL_GPL(add_input_randomness);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-07-02 19:52:16 +08:00
|
|
|
static DEFINE_PER_CPU(struct fast_pool, irq_randomness);
|
|
|
|
|
2014-06-15 09:43:13 +08:00
|
|
|
#ifdef ADD_INTERRUPT_BENCH
|
|
|
|
static unsigned long avg_cycles, avg_deviation;
|
|
|
|
|
|
|
|
#define AVG_SHIFT 8 /* Exponential average factor k=1/256 */
|
|
|
|
#define FIXED_1_2 (1 << (AVG_SHIFT-1))
|
|
|
|
|
|
|
|
static void add_interrupt_bench(cycles_t start)
|
|
|
|
{
|
|
|
|
long delta = random_get_entropy() - start;
|
|
|
|
|
|
|
|
/* Use a weighted moving average */
|
|
|
|
delta = delta - ((avg_cycles + FIXED_1_2) >> AVG_SHIFT);
|
|
|
|
avg_cycles += delta;
|
|
|
|
/* And average deviation */
|
|
|
|
delta = abs(delta) - ((avg_deviation + FIXED_1_2) >> AVG_SHIFT);
|
|
|
|
avg_deviation += delta;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
#define add_interrupt_bench(x)
|
|
|
|
#endif
|
|
|
|
|
2014-06-16 04:59:24 +08:00
|
|
|
static __u32 get_reg(struct fast_pool *f, struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
__u32 *ptr = (__u32 *) regs;
|
2017-06-08 07:01:32 +08:00
|
|
|
unsigned int idx;
|
2014-06-16 04:59:24 +08:00
|
|
|
|
|
|
|
if (regs == NULL)
|
|
|
|
return 0;
|
2017-06-08 07:01:32 +08:00
|
|
|
idx = READ_ONCE(f->reg_idx);
|
|
|
|
if (idx >= sizeof(struct pt_regs) / sizeof(__u32))
|
|
|
|
idx = 0;
|
|
|
|
ptr += idx++;
|
|
|
|
WRITE_ONCE(f->reg_idx, idx);
|
2017-04-30 15:49:21 +08:00
|
|
|
return *ptr;
|
2014-06-16 04:59:24 +08:00
|
|
|
}
|
|
|
|
|
2012-07-02 19:52:16 +08:00
|
|
|
void add_interrupt_randomness(int irq, int irq_flags)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2012-07-02 19:52:16 +08:00
|
|
|
struct entropy_store *r;
|
2014-08-18 01:30:29 +08:00
|
|
|
struct fast_pool *fast_pool = this_cpu_ptr(&irq_randomness);
|
2012-07-02 19:52:16 +08:00
|
|
|
struct pt_regs *regs = get_irq_regs();
|
|
|
|
unsigned long now = jiffies;
|
2013-09-23 03:24:02 +08:00
|
|
|
cycles_t cycles = random_get_entropy();
|
2014-06-15 09:43:13 +08:00
|
|
|
__u32 c_high, j_high;
|
2013-09-23 03:24:02 +08:00
|
|
|
__u64 ip;
|
2014-03-18 07:36:28 +08:00
|
|
|
unsigned long seed;
|
2014-06-11 10:46:37 +08:00
|
|
|
int credit = 0;
|
2008-08-20 11:50:08 +08:00
|
|
|
|
2014-06-16 04:59:24 +08:00
|
|
|
if (cycles == 0)
|
|
|
|
cycles = get_reg(fast_pool, regs);
|
2013-09-23 03:24:02 +08:00
|
|
|
c_high = (sizeof(cycles) > 4) ? cycles >> 32 : 0;
|
|
|
|
j_high = (sizeof(now) > 4) ? now >> 32 : 0;
|
2014-06-15 09:43:13 +08:00
|
|
|
fast_pool->pool[0] ^= cycles ^ j_high ^ irq;
|
|
|
|
fast_pool->pool[1] ^= now ^ c_high;
|
2013-09-23 03:24:02 +08:00
|
|
|
ip = regs ? instruction_pointer(regs) : _RET_IP_;
|
2014-06-15 09:43:13 +08:00
|
|
|
fast_pool->pool[2] ^= ip;
|
2014-06-16 04:59:24 +08:00
|
|
|
fast_pool->pool[3] ^= (sizeof(ip) > 4) ? ip >> 32 :
|
|
|
|
get_reg(fast_pool, regs);
|
2008-08-20 11:50:08 +08:00
|
|
|
|
2014-06-15 09:43:13 +08:00
|
|
|
fast_mix(fast_pool);
|
|
|
|
add_interrupt_bench(cycles);
|
2008-08-20 11:50:08 +08:00
|
|
|
|
2018-04-12 01:27:52 +08:00
|
|
|
if (unlikely(crng_init == 0)) {
|
2016-06-13 06:13:36 +08:00
|
|
|
if ((fast_pool->count >= 64) &&
|
|
|
|
crng_fast_load((char *) fast_pool->pool,
|
|
|
|
sizeof(fast_pool->pool))) {
|
|
|
|
fast_pool->count = 0;
|
|
|
|
fast_pool->last = now;
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-06-16 04:59:24 +08:00
|
|
|
if ((fast_pool->count < 64) &&
|
|
|
|
!time_after(now, fast_pool->last + HZ))
|
2005-04-17 06:20:36 +08:00
|
|
|
return;
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
r = &input_pool;
|
2014-06-14 15:06:57 +08:00
|
|
|
if (!spin_trylock(&r->lock))
|
2014-06-11 10:46:37 +08:00
|
|
|
return;
|
2014-03-18 07:36:28 +08:00
|
|
|
|
2014-06-11 10:46:37 +08:00
|
|
|
fast_pool->last = now;
|
2014-06-11 11:09:20 +08:00
|
|
|
__mix_pool_bytes(r, &fast_pool->pool, sizeof(fast_pool->pool));
|
2014-03-18 07:36:28 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have architectural seed generator, produce a seed and
|
2014-07-17 17:27:30 +08:00
|
|
|
* add it to the pool. For the sake of paranoia don't let the
|
|
|
|
* architectural seed generator dominate the input from the
|
|
|
|
* interrupt noise.
|
2014-03-18 07:36:28 +08:00
|
|
|
*/
|
|
|
|
if (arch_get_random_seed_long(&seed)) {
|
2014-06-11 11:09:20 +08:00
|
|
|
__mix_pool_bytes(r, &seed, sizeof(seed));
|
2014-07-17 17:27:30 +08:00
|
|
|
credit = 1;
|
2014-03-18 07:36:28 +08:00
|
|
|
}
|
2014-06-11 10:46:37 +08:00
|
|
|
spin_unlock(&r->lock);
|
2014-03-18 07:36:28 +08:00
|
|
|
|
2014-06-16 04:59:24 +08:00
|
|
|
fast_pool->count = 0;
|
2014-03-18 07:36:28 +08:00
|
|
|
|
2014-06-16 04:59:24 +08:00
|
|
|
/* award one bit for the contents of the fast pool */
|
|
|
|
credit_entropy_bits(r, credit + 1);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2016-05-02 14:14:34 +08:00
|
|
|
EXPORT_SYMBOL_GPL(add_interrupt_randomness);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
[PATCH] BLOCK: Make it possible to disable the block layer [try #6]
Make it possible to disable the block layer. Not all embedded devices require
it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
the block layer to be present.
This patch does the following:
(*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
support.
(*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
an item that uses the block layer. This includes:
(*) Block I/O tracing.
(*) Disk partition code.
(*) All filesystems that are block based, eg: Ext3, ReiserFS, ISOFS.
(*) The SCSI layer. As far as I can tell, even SCSI chardevs use the
block layer to do scheduling. Some drivers that use SCSI facilities -
such as USB storage - end up disabled indirectly from this.
(*) Various block-based device drivers, such as IDE and the old CDROM
drivers.
(*) MTD blockdev handling and FTL.
(*) JFFS - which uses set_bdev_super(), something it could avoid doing by
taking a leaf out of JFFS2's book.
(*) Makes most of the contents of linux/blkdev.h, linux/buffer_head.h and
linux/elevator.h contingent on CONFIG_BLOCK being set. sector_div() is,
however, still used in places, and so is still available.
(*) Also made contingent are the contents of linux/mpage.h, linux/genhd.h and
parts of linux/fs.h.
(*) Makes a number of files in fs/ contingent on CONFIG_BLOCK.
(*) Makes mm/bounce.c (bounce buffering) contingent on CONFIG_BLOCK.
(*) set_page_dirty() doesn't call __set_page_dirty_buffers() if CONFIG_BLOCK
is not enabled.
(*) fs/no-block.c is created to hold out-of-line stubs and things that are
required when CONFIG_BLOCK is not set:
(*) Default blockdev file operations (to give error ENODEV on opening).
(*) Makes some /proc changes:
(*) /proc/devices does not list any blockdevs.
(*) /proc/diskstats and /proc/partitions are contingent on CONFIG_BLOCK.
(*) Makes some compat ioctl handling contingent on CONFIG_BLOCK.
(*) If CONFIG_BLOCK is not defined, makes sys_quotactl() return -ENODEV if
given command other than Q_SYNC or if a special device is specified.
(*) In init/do_mounts.c, no reference is made to the blockdev routines if
CONFIG_BLOCK is not defined. This does not prohibit NFS roots or JFFS2.
(*) The bdflush, ioprio_set and ioprio_get syscalls can now be absent (return
error ENOSYS by way of cond_syscall if so).
(*) The seclvl_bd_claim() and seclvl_bd_release() security calls do nothing if
CONFIG_BLOCK is not set, since they can't then happen.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2006-10-01 02:45:40 +08:00
|
|
|
#ifdef CONFIG_BLOCK
|
2005-04-17 06:20:36 +08:00
|
|
|
void add_disk_randomness(struct gendisk *disk)
|
|
|
|
{
|
|
|
|
if (!disk || !disk->random)
|
|
|
|
return;
|
|
|
|
/* first major is 1, so we get >= 0x200 here */
|
2008-09-03 15:01:48 +08:00
|
|
|
add_timer_randomness(disk->random, 0x100 + disk_devt(disk));
|
2013-10-04 00:02:37 +08:00
|
|
|
trace_add_disk_randomness(disk_devt(disk), ENTROPY_BITS(&input_pool));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2014-04-25 15:36:37 +08:00
|
|
|
EXPORT_SYMBOL_GPL(add_disk_randomness);
|
[PATCH] BLOCK: Make it possible to disable the block layer [try #6]
Make it possible to disable the block layer. Not all embedded devices require
it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
the block layer to be present.
This patch does the following:
(*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
support.
(*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
an item that uses the block layer. This includes:
(*) Block I/O tracing.
(*) Disk partition code.
(*) All filesystems that are block based, eg: Ext3, ReiserFS, ISOFS.
(*) The SCSI layer. As far as I can tell, even SCSI chardevs use the
block layer to do scheduling. Some drivers that use SCSI facilities -
such as USB storage - end up disabled indirectly from this.
(*) Various block-based device drivers, such as IDE and the old CDROM
drivers.
(*) MTD blockdev handling and FTL.
(*) JFFS - which uses set_bdev_super(), something it could avoid doing by
taking a leaf out of JFFS2's book.
(*) Makes most of the contents of linux/blkdev.h, linux/buffer_head.h and
linux/elevator.h contingent on CONFIG_BLOCK being set. sector_div() is,
however, still used in places, and so is still available.
(*) Also made contingent are the contents of linux/mpage.h, linux/genhd.h and
parts of linux/fs.h.
(*) Makes a number of files in fs/ contingent on CONFIG_BLOCK.
(*) Makes mm/bounce.c (bounce buffering) contingent on CONFIG_BLOCK.
(*) set_page_dirty() doesn't call __set_page_dirty_buffers() if CONFIG_BLOCK
is not enabled.
(*) fs/no-block.c is created to hold out-of-line stubs and things that are
required when CONFIG_BLOCK is not set:
(*) Default blockdev file operations (to give error ENODEV on opening).
(*) Makes some /proc changes:
(*) /proc/devices does not list any blockdevs.
(*) /proc/diskstats and /proc/partitions are contingent on CONFIG_BLOCK.
(*) Makes some compat ioctl handling contingent on CONFIG_BLOCK.
(*) If CONFIG_BLOCK is not defined, makes sys_quotactl() return -ENODEV if
given command other than Q_SYNC or if a special device is specified.
(*) In init/do_mounts.c, no reference is made to the blockdev routines if
CONFIG_BLOCK is not defined. This does not prohibit NFS roots or JFFS2.
(*) The bdflush, ioprio_set and ioprio_get syscalls can now be absent (return
error ENOSYS by way of cond_syscall if so).
(*) The seclvl_bd_claim() and seclvl_bd_release() security calls do nothing if
CONFIG_BLOCK is not set, since they can't then happen.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2006-10-01 02:45:40 +08:00
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*********************************************************************
|
|
|
|
*
|
|
|
|
* Entropy extraction routines
|
|
|
|
*
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
/*
|
2011-03-31 09:57:33 +08:00
|
|
|
* This utility inline function is responsible for transferring entropy
|
2005-04-17 06:20:36 +08:00
|
|
|
* from the primary pool to the secondary extraction pool. We make
|
|
|
|
* sure we pull enough for a 'catastrophic reseed'.
|
|
|
|
*/
|
2013-10-03 13:08:15 +08:00
|
|
|
static void _xfer_secondary_pool(struct entropy_store *r, size_t nbytes);
|
2005-04-17 06:20:36 +08:00
|
|
|
static void xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
|
|
|
|
{
|
2014-06-11 11:18:16 +08:00
|
|
|
if (!r->pull ||
|
|
|
|
r->entropy_count >= (nbytes << (ENTROPY_SHIFT + 3)) ||
|
|
|
|
r->entropy_count > r->poolinfo->poolfracbits)
|
|
|
|
return;
|
|
|
|
|
|
|
|
_xfer_secondary_pool(r, nbytes);
|
2013-10-03 13:08:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void _xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
|
|
|
|
{
|
|
|
|
__u32 tmp[OUTPUT_POOL_WORDS];
|
|
|
|
|
|
|
|
int bytes = nbytes;
|
|
|
|
|
2013-12-07 10:28:03 +08:00
|
|
|
/* pull at least as much as a wakeup */
|
|
|
|
bytes = max_t(int, bytes, random_read_wakeup_bits / 8);
|
2013-10-03 13:08:15 +08:00
|
|
|
/* but never more than the buffer size */
|
|
|
|
bytes = min_t(int, bytes, sizeof(tmp));
|
|
|
|
|
2013-10-04 00:02:37 +08:00
|
|
|
trace_xfer_secondary_pool(r->name, bytes * 8, nbytes * 8,
|
|
|
|
ENTROPY_BITS(r), ENTROPY_BITS(r->pull));
|
2013-10-03 13:08:15 +08:00
|
|
|
bytes = extract_entropy(r->pull, tmp, bytes,
|
2016-12-28 06:40:59 +08:00
|
|
|
random_read_wakeup_bits / 8, 0);
|
2014-06-11 11:09:20 +08:00
|
|
|
mix_pool_bytes(r, tmp, bytes);
|
2013-10-03 13:08:15 +08:00
|
|
|
credit_entropy_bits(r, bytes*8);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Used as a workqueue function so that when the input pool is getting
|
|
|
|
* full, we can "spill over" some entropy to the output pools. That
|
|
|
|
* way the output pools can store some of the excess entropy instead
|
|
|
|
* of letting it go to waste.
|
|
|
|
*/
|
|
|
|
static void push_to_pool(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct entropy_store *r = container_of(work, struct entropy_store,
|
|
|
|
push_work);
|
|
|
|
BUG_ON(!r);
|
2013-12-07 10:28:03 +08:00
|
|
|
_xfer_secondary_pool(r, random_read_wakeup_bits/8);
|
2013-10-03 13:08:15 +08:00
|
|
|
trace_push_to_pool(r->name, r->entropy_count >> ENTROPY_SHIFT,
|
|
|
|
r->pull->entropy_count >> ENTROPY_SHIFT);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-11-30 04:50:06 +08:00
|
|
|
* This function decides how many bytes to actually take from the
|
|
|
|
* given pool, and also debits the entropy count accordingly.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
static size_t account(struct entropy_store *r, size_t nbytes, int min,
|
|
|
|
int reserved)
|
|
|
|
{
|
2016-12-28 06:40:59 +08:00
|
|
|
int entropy_count, orig, have_bytes;
|
2014-07-19 05:26:41 +08:00
|
|
|
size_t ibytes, nfrac;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-09-11 11:16:17 +08:00
|
|
|
BUG_ON(r->entropy_count > r->poolinfo->poolfracbits);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* Can we pull enough? */
|
2013-05-25 06:55:33 +08:00
|
|
|
retry:
|
locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
Please do not apply this to mainline directly, instead please re-run the
coccinelle script shown below and apply its output.
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't harmful, and changing them results in
churn.
However, for some features, the read/write distinction is critical to
correct operation. To distinguish these cases, separate read/write
accessors must be used. This patch migrates (most) remaining
ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
coccinelle script:
----
// Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
// WRITE_ONCE()
// $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24 05:07:29 +08:00
|
|
|
entropy_count = orig = READ_ONCE(r->entropy_count);
|
2013-09-11 11:16:17 +08:00
|
|
|
ibytes = nbytes;
|
2016-12-28 06:40:59 +08:00
|
|
|
/* never pull more than available */
|
|
|
|
have_bytes = entropy_count >> (ENTROPY_SHIFT + 3);
|
random: fix nasty entropy accounting bug
Commit 0fb7a01af5b0 "random: simplify accounting code", introduced in
v3.15, has a very nasty accounting problem when the entropy pool has
has fewer bytes of entropy than the number of requested reserved
bytes. In that case, "have_bytes - reserved" goes negative, and since
size_t is unsigned, the expression:
ibytes = min_t(size_t, ibytes, have_bytes - reserved);
... does not do the right thing. This is rather bad, because it
defeats the catastrophic reseeding feature in the
xfer_secondary_pool() path.
It also can cause the "BUG: spinlock trylock failure on UP" for some
kernel configurations when prandom_reseed() calls get_random_bytes()
in the early init, since when the entropy count gets corrupted,
credit_entropy_bits() erroneously believes that the nonblocking pool
has been fully initialized (when in fact it is not), and so it calls
prandom_reseed(true) recursively leading to the spinlock BUG.
The logic is *not* the same it was originally, but in the cases where
it matters, the behavior is the same, and the resulting code is
hopefully easier to read and understand.
Fixes: 0fb7a01af5b0 "random: simplify accounting code"
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: Greg Price <price@mit.edu>
Cc: stable@vger.kernel.org #v3.15
2014-06-16 09:04:32 +08:00
|
|
|
|
2016-12-28 06:40:59 +08:00
|
|
|
if ((have_bytes -= reserved) < 0)
|
|
|
|
have_bytes = 0;
|
|
|
|
ibytes = min_t(size_t, ibytes, have_bytes);
|
2013-12-06 08:32:19 +08:00
|
|
|
if (ibytes < min)
|
2013-09-11 11:16:17 +08:00
|
|
|
ibytes = 0;
|
2014-07-19 05:26:41 +08:00
|
|
|
|
|
|
|
if (unlikely(entropy_count < 0)) {
|
|
|
|
pr_warn("random: negative entropy count: pool %s count %d\n",
|
|
|
|
r->name, entropy_count);
|
|
|
|
WARN_ON(1);
|
|
|
|
entropy_count = 0;
|
|
|
|
}
|
|
|
|
nfrac = ibytes << (ENTROPY_SHIFT + 3);
|
|
|
|
if ((size_t) entropy_count > nfrac)
|
|
|
|
entropy_count -= nfrac;
|
|
|
|
else
|
random: fix nasty entropy accounting bug
Commit 0fb7a01af5b0 "random: simplify accounting code", introduced in
v3.15, has a very nasty accounting problem when the entropy pool has
has fewer bytes of entropy than the number of requested reserved
bytes. In that case, "have_bytes - reserved" goes negative, and since
size_t is unsigned, the expression:
ibytes = min_t(size_t, ibytes, have_bytes - reserved);
... does not do the right thing. This is rather bad, because it
defeats the catastrophic reseeding feature in the
xfer_secondary_pool() path.
It also can cause the "BUG: spinlock trylock failure on UP" for some
kernel configurations when prandom_reseed() calls get_random_bytes()
in the early init, since when the entropy count gets corrupted,
credit_entropy_bits() erroneously believes that the nonblocking pool
has been fully initialized (when in fact it is not), and so it calls
prandom_reseed(true) recursively leading to the spinlock BUG.
The logic is *not* the same it was originally, but in the cases where
it matters, the behavior is the same, and the resulting code is
hopefully easier to read and understand.
Fixes: 0fb7a01af5b0 "random: simplify accounting code"
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: Greg Price <price@mit.edu>
Cc: stable@vger.kernel.org #v3.15
2014-06-16 09:04:32 +08:00
|
|
|
entropy_count = 0;
|
2014-05-17 09:40:41 +08:00
|
|
|
|
2013-12-06 08:32:19 +08:00
|
|
|
if (cmpxchg(&r->entropy_count, orig, entropy_count) != orig)
|
|
|
|
goto retry;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-10-04 00:02:37 +08:00
|
|
|
trace_debit_entropy(r->name, 8 * ibytes);
|
2013-12-06 08:32:19 +08:00
|
|
|
if (ibytes &&
|
2013-12-07 10:28:03 +08:00
|
|
|
(r->entropy_count >> ENTROPY_SHIFT) < random_write_wakeup_bits) {
|
2013-03-05 00:59:12 +08:00
|
|
|
wake_up_interruptible(&random_write_wait);
|
|
|
|
kill_fasync(&fasync, SIGIO, POLL_OUT);
|
|
|
|
}
|
|
|
|
|
2013-09-11 11:16:17 +08:00
|
|
|
return ibytes;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-11-30 04:50:06 +08:00
|
|
|
/*
|
|
|
|
* This function does the actual extraction for extract_entropy and
|
|
|
|
* extract_entropy_user.
|
|
|
|
*
|
|
|
|
* Note: we assume that .poolwords is a multiple of 16 words.
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
static void extract_buf(struct entropy_store *r, __u8 *out)
|
|
|
|
{
|
2007-05-30 10:54:27 +08:00
|
|
|
int i;
|
2012-07-28 10:26:08 +08:00
|
|
|
union {
|
|
|
|
__u32 w[5];
|
2013-09-22 06:06:02 +08:00
|
|
|
unsigned long l[LONGS(20)];
|
2012-07-28 10:26:08 +08:00
|
|
|
} hash;
|
|
|
|
__u32 workspace[SHA_WORKSPACE_WORDS];
|
2012-07-04 22:38:30 +08:00
|
|
|
unsigned long flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-09-22 06:06:02 +08:00
|
|
|
/*
|
2013-11-30 03:58:06 +08:00
|
|
|
* If we have an architectural hardware random number
|
2013-12-18 10:16:39 +08:00
|
|
|
* generator, use it for SHA's initial vector
|
2013-09-22 06:06:02 +08:00
|
|
|
*/
|
2013-12-18 10:16:39 +08:00
|
|
|
sha_init(hash.w);
|
2013-09-22 06:06:02 +08:00
|
|
|
for (i = 0; i < LONGS(20); i++) {
|
|
|
|
unsigned long v;
|
|
|
|
if (!arch_get_random_long(&v))
|
|
|
|
break;
|
2013-12-18 10:16:39 +08:00
|
|
|
hash.l[i] = v;
|
2013-09-22 06:06:02 +08:00
|
|
|
}
|
|
|
|
|
2013-12-18 10:16:39 +08:00
|
|
|
/* Generate a hash across the pool, 16 words (512 bits) at a time */
|
|
|
|
spin_lock_irqsave(&r->lock, flags);
|
|
|
|
for (i = 0; i < r->poolinfo->poolwords; i += 16)
|
|
|
|
sha_transform(hash.w, (__u8 *)(r->pool + i), workspace);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2008-04-29 16:03:00 +08:00
|
|
|
* We mix the hash back into the pool to prevent backtracking
|
|
|
|
* attacks (where the attacker knows the state of the pool
|
|
|
|
* plus the current outputs, and attempts to find previous
|
|
|
|
* ouputs), unless the hash function can be inverted. By
|
|
|
|
* mixing at least a SHA1 worth of hash data back, we make
|
|
|
|
* brute-forcing the feedback as hard as brute-forcing the
|
|
|
|
* hash.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2014-06-11 11:09:20 +08:00
|
|
|
__mix_pool_bytes(r, hash.w, sizeof(hash.w));
|
2012-07-04 22:38:30 +08:00
|
|
|
spin_unlock_irqrestore(&r->lock, flags);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-08-27 11:16:35 +08:00
|
|
|
memzero_explicit(workspace, sizeof(workspace));
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
2008-04-29 16:03:00 +08:00
|
|
|
* In case the hash function has some recognizable output
|
|
|
|
* pattern, we fold it in half. Thus, we always feed back
|
|
|
|
* twice as much data as we output.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2012-07-28 10:26:08 +08:00
|
|
|
hash.w[0] ^= hash.w[3];
|
|
|
|
hash.w[1] ^= hash.w[4];
|
|
|
|
hash.w[2] ^= rol32(hash.w[2], 16);
|
|
|
|
|
|
|
|
memcpy(out, &hash, EXTRACT_SIZE);
|
2014-08-27 11:16:35 +08:00
|
|
|
memzero_explicit(&hash, sizeof(hash));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
static ssize_t _extract_entropy(struct entropy_store *r, void *buf,
|
|
|
|
size_t nbytes, int fips)
|
|
|
|
{
|
|
|
|
ssize_t ret = 0, i;
|
|
|
|
__u8 tmp[EXTRACT_SIZE];
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
while (nbytes) {
|
|
|
|
extract_buf(r, tmp);
|
|
|
|
|
|
|
|
if (fips) {
|
|
|
|
spin_lock_irqsave(&r->lock, flags);
|
|
|
|
if (!memcmp(tmp, r->last_data, EXTRACT_SIZE))
|
|
|
|
panic("Hardware RNG duplicated output!\n");
|
|
|
|
memcpy(r->last_data, tmp, EXTRACT_SIZE);
|
|
|
|
spin_unlock_irqrestore(&r->lock, flags);
|
|
|
|
}
|
|
|
|
i = min_t(int, nbytes, EXTRACT_SIZE);
|
|
|
|
memcpy(buf, tmp, i);
|
|
|
|
nbytes -= i;
|
|
|
|
buf += i;
|
|
|
|
ret += i;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Wipe data just returned from memory */
|
|
|
|
memzero_explicit(tmp, sizeof(tmp));
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-11-30 04:50:06 +08:00
|
|
|
/*
|
|
|
|
* This function extracts randomness from the "entropy pool", and
|
|
|
|
* returns it in a buffer.
|
|
|
|
*
|
|
|
|
* The min parameter specifies the minimum amount we can pull before
|
|
|
|
* failing to avoid races that defeat catastrophic reseeding while the
|
|
|
|
* reserved parameter indicates how much entropy we must leave in the
|
|
|
|
* pool after each pull to avoid starving other readers.
|
|
|
|
*/
|
2008-04-29 16:02:55 +08:00
|
|
|
static ssize_t extract_entropy(struct entropy_store *r, void *buf,
|
2012-07-04 22:38:30 +08:00
|
|
|
size_t nbytes, int min, int reserved)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
__u8 tmp[EXTRACT_SIZE];
|
2013-05-25 06:55:31 +08:00
|
|
|
unsigned long flags;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-11-06 23:42:42 +08:00
|
|
|
/* if last_data isn't primed, we need EXTRACT_SIZE extra bytes */
|
2013-05-25 06:55:31 +08:00
|
|
|
if (fips_enabled) {
|
|
|
|
spin_lock_irqsave(&r->lock, flags);
|
|
|
|
if (!r->last_data_init) {
|
2013-09-22 07:42:41 +08:00
|
|
|
r->last_data_init = 1;
|
2013-05-25 06:55:31 +08:00
|
|
|
spin_unlock_irqrestore(&r->lock, flags);
|
|
|
|
trace_extract_entropy(r->name, EXTRACT_SIZE,
|
2013-09-11 11:16:17 +08:00
|
|
|
ENTROPY_BITS(r), _RET_IP_);
|
2013-05-25 06:55:31 +08:00
|
|
|
xfer_secondary_pool(r, EXTRACT_SIZE);
|
|
|
|
extract_buf(r, tmp);
|
|
|
|
spin_lock_irqsave(&r->lock, flags);
|
|
|
|
memcpy(r->last_data, tmp, EXTRACT_SIZE);
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&r->lock, flags);
|
|
|
|
}
|
2012-11-06 23:42:42 +08:00
|
|
|
|
2013-09-11 11:16:17 +08:00
|
|
|
trace_extract_entropy(r->name, nbytes, ENTROPY_BITS(r), _RET_IP_);
|
2005-04-17 06:20:36 +08:00
|
|
|
xfer_secondary_pool(r, nbytes);
|
|
|
|
nbytes = account(r, nbytes, min, reserved);
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
return _extract_entropy(r, buf, nbytes, fips_enabled);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-11-30 04:50:06 +08:00
|
|
|
/*
|
|
|
|
* This function extracts randomness from the "entropy pool", and
|
|
|
|
* returns it in a userspace buffer.
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
static ssize_t extract_entropy_user(struct entropy_store *r, void __user *buf,
|
|
|
|
size_t nbytes)
|
|
|
|
{
|
|
|
|
ssize_t ret = 0, i;
|
|
|
|
__u8 tmp[EXTRACT_SIZE];
|
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
2014-07-17 16:13:05 +08:00
|
|
|
int large_request = (nbytes > 256);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-09-11 11:16:17 +08:00
|
|
|
trace_extract_entropy_user(r->name, nbytes, ENTROPY_BITS(r), _RET_IP_);
|
2005-04-17 06:20:36 +08:00
|
|
|
xfer_secondary_pool(r, nbytes);
|
|
|
|
nbytes = account(r, nbytes, 0, 0);
|
|
|
|
|
|
|
|
while (nbytes) {
|
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
2014-07-17 16:13:05 +08:00
|
|
|
if (large_request && need_resched()) {
|
2005-04-17 06:20:36 +08:00
|
|
|
if (signal_pending(current)) {
|
|
|
|
if (ret == 0)
|
|
|
|
ret = -ERESTARTSYS;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
schedule();
|
|
|
|
}
|
|
|
|
|
|
|
|
extract_buf(r, tmp);
|
|
|
|
i = min_t(int, nbytes, EXTRACT_SIZE);
|
|
|
|
if (copy_to_user(buf, tmp, i)) {
|
|
|
|
ret = -EFAULT;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
nbytes -= i;
|
|
|
|
buf += i;
|
|
|
|
ret += i;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Wipe data just returned from memory */
|
2014-08-27 11:16:35 +08:00
|
|
|
memzero_explicit(tmp, sizeof(tmp));
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-06-08 16:16:59 +08:00
|
|
|
#define warn_unseeded_randomness(previous) \
|
|
|
|
_warn_unseeded_randomness(__func__, (void *) _RET_IP_, (previous))
|
|
|
|
|
|
|
|
static void _warn_unseeded_randomness(const char *func_name, void *caller,
|
|
|
|
void **previous)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_WARN_ALL_UNSEEDED_RANDOM
|
|
|
|
const bool print_once = false;
|
|
|
|
#else
|
|
|
|
static bool print_once __read_mostly;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if (print_once ||
|
|
|
|
crng_ready() ||
|
|
|
|
(previous && (caller == READ_ONCE(*previous))))
|
|
|
|
return;
|
|
|
|
WRITE_ONCE(*previous, caller);
|
|
|
|
#ifndef CONFIG_WARN_ALL_UNSEEDED_RANDOM
|
|
|
|
print_once = true;
|
|
|
|
#endif
|
2017-08-09 00:28:41 +08:00
|
|
|
pr_notice("random: %s called from %pS with crng_init=%d\n",
|
2017-06-08 16:16:59 +08:00
|
|
|
func_name, caller, crng_init);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* This function is the exported kernel interface. It returns some
|
random: add new get_random_bytes_arch() function
Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present. Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.
The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door. (For example, an
increasing counter encrypted by an AES key known to the NSA.)
It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
--- especially since Bull Mountain is documented to use AES as a
whitener. Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel. Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.
Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.
This way we get almost of the benefits of the HW RNG without any
potential liabilities. The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.
For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
2012-07-05 22:35:23 +08:00
|
|
|
* number of good random numbers, suitable for key generation, seeding
|
2013-11-30 03:59:45 +08:00
|
|
|
* TCP sequence numbers, etc. It does not rely on the hardware random
|
|
|
|
* number generator. For random bytes direct from the hardware RNG
|
2017-06-08 07:58:56 +08:00
|
|
|
* (when available), use get_random_bytes_arch(). In order to ensure
|
|
|
|
* that the randomness provided by this function is okay, the function
|
|
|
|
* wait_for_random_bytes() should be called and return 0 at least once
|
|
|
|
* at any point prior.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2017-06-08 16:16:59 +08:00
|
|
|
static void _get_random_bytes(void *buf, int nbytes)
|
random: add new get_random_bytes_arch() function
Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present. Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.
The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door. (For example, an
increasing counter encrypted by an AES key known to the NSA.)
It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
--- especially since Bull Mountain is documented to use AES as a
whitener. Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel. Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.
Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.
This way we get almost of the benefits of the HW RNG without any
potential liabilities. The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.
For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
2012-07-05 22:35:23 +08:00
|
|
|
{
|
2017-11-23 03:51:39 +08:00
|
|
|
__u32 tmp[CHACHA20_BLOCK_WORDS];
|
2016-06-13 06:13:36 +08:00
|
|
|
|
2013-09-13 02:10:25 +08:00
|
|
|
trace_get_random_bytes(nbytes, _RET_IP_);
|
2016-06-13 06:13:36 +08:00
|
|
|
|
|
|
|
while (nbytes >= CHACHA20_BLOCK_SIZE) {
|
|
|
|
extract_crng(buf);
|
|
|
|
buf += CHACHA20_BLOCK_SIZE;
|
|
|
|
nbytes -= CHACHA20_BLOCK_SIZE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (nbytes > 0) {
|
|
|
|
extract_crng(tmp);
|
|
|
|
memcpy(buf, tmp, nbytes);
|
2016-05-05 01:29:18 +08:00
|
|
|
crng_backtrack_protect(tmp, nbytes);
|
|
|
|
} else
|
|
|
|
crng_backtrack_protect(tmp, CHACHA20_BLOCK_SIZE);
|
|
|
|
memzero_explicit(tmp, sizeof(tmp));
|
random: add new get_random_bytes_arch() function
Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present. Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.
The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door. (For example, an
increasing counter encrypted by an AES key known to the NSA.)
It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
--- especially since Bull Mountain is documented to use AES as a
whitener. Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel. Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.
Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.
This way we get almost of the benefits of the HW RNG without any
potential liabilities. The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.
For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
2012-07-05 22:35:23 +08:00
|
|
|
}
|
2017-06-08 16:16:59 +08:00
|
|
|
|
|
|
|
void get_random_bytes(void *buf, int nbytes)
|
|
|
|
{
|
|
|
|
static void *previous;
|
|
|
|
|
|
|
|
warn_unseeded_randomness(&previous);
|
|
|
|
_get_random_bytes(buf, nbytes);
|
|
|
|
}
|
random: add new get_random_bytes_arch() function
Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present. Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.
The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door. (For example, an
increasing counter encrypted by an AES key known to the NSA.)
It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
--- especially since Bull Mountain is documented to use AES as a
whitener. Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel. Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.
Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.
This way we get almost of the benefits of the HW RNG without any
potential liabilities. The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.
For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
2012-07-05 22:35:23 +08:00
|
|
|
EXPORT_SYMBOL(get_random_bytes);
|
|
|
|
|
2017-06-08 07:58:56 +08:00
|
|
|
/*
|
|
|
|
* Wait for the urandom pool to be seeded and thus guaranteed to supply
|
|
|
|
* cryptographically secure random numbers. This applies to: the /dev/urandom
|
|
|
|
* device, the get_random_bytes function, and the get_random_{u32,u64,int,long}
|
|
|
|
* family of functions. Using any of these functions without first calling
|
|
|
|
* this function forfeits the guarantee of security.
|
|
|
|
*
|
|
|
|
* Returns: 0 if the urandom pool has been seeded.
|
|
|
|
* -ERESTARTSYS if the function was interrupted by a signal.
|
|
|
|
*/
|
|
|
|
int wait_for_random_bytes(void)
|
|
|
|
{
|
|
|
|
if (likely(crng_ready()))
|
|
|
|
return 0;
|
|
|
|
return wait_event_interruptible(crng_init_wait, crng_ready());
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(wait_for_random_bytes);
|
|
|
|
|
2015-06-09 18:19:39 +08:00
|
|
|
/*
|
|
|
|
* Add a callback function that will be invoked when the nonblocking
|
|
|
|
* pool is initialised.
|
|
|
|
*
|
|
|
|
* returns: 0 if callback is successfully added
|
|
|
|
* -EALREADY if pool is already initialised (callback not called)
|
|
|
|
* -ENOENT if module for callback is not alive
|
|
|
|
*/
|
|
|
|
int add_random_ready_callback(struct random_ready_callback *rdy)
|
|
|
|
{
|
|
|
|
struct module *owner;
|
|
|
|
unsigned long flags;
|
|
|
|
int err = -EALREADY;
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
if (crng_ready())
|
2015-06-09 18:19:39 +08:00
|
|
|
return err;
|
|
|
|
|
|
|
|
owner = rdy->owner;
|
|
|
|
if (!try_module_get(owner))
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&random_ready_list_lock, flags);
|
2016-06-13 06:13:36 +08:00
|
|
|
if (crng_ready())
|
2015-06-09 18:19:39 +08:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
owner = NULL;
|
|
|
|
|
|
|
|
list_add(&rdy->list, &random_ready_list);
|
|
|
|
err = 0;
|
|
|
|
|
|
|
|
out:
|
|
|
|
spin_unlock_irqrestore(&random_ready_list_lock, flags);
|
|
|
|
|
|
|
|
module_put(owner);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(add_random_ready_callback);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Delete a previously registered readiness callback function.
|
|
|
|
*/
|
|
|
|
void del_random_ready_callback(struct random_ready_callback *rdy)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
struct module *owner = NULL;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&random_ready_list_lock, flags);
|
|
|
|
if (!list_empty(&rdy->list)) {
|
|
|
|
list_del_init(&rdy->list);
|
|
|
|
owner = rdy->owner;
|
|
|
|
}
|
|
|
|
spin_unlock_irqrestore(&random_ready_list_lock, flags);
|
|
|
|
|
|
|
|
module_put(owner);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(del_random_ready_callback);
|
|
|
|
|
random: add new get_random_bytes_arch() function
Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present. Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.
The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door. (For example, an
increasing counter encrypted by an AES key known to the NSA.)
It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
--- especially since Bull Mountain is documented to use AES as a
whitener. Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel. Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.
Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.
This way we get almost of the benefits of the HW RNG without any
potential liabilities. The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.
For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
2012-07-05 22:35:23 +08:00
|
|
|
/*
|
|
|
|
* This function will use the architecture-specific hardware random
|
|
|
|
* number generator if it is available. The arch-specific hw RNG will
|
|
|
|
* almost certainly be faster than what we can do in software, but it
|
|
|
|
* is impossible to verify that it is implemented securely (as
|
|
|
|
* opposed, to, say, the AES encryption of a sequence number using a
|
|
|
|
* key known by the NSA). So it's useful if we need the speed, but
|
|
|
|
* only if we're willing to trust the hardware manufacturer not to
|
|
|
|
* have put in a back door.
|
|
|
|
*/
|
|
|
|
void get_random_bytes_arch(void *buf, int nbytes)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2011-08-01 04:54:50 +08:00
|
|
|
char *p = buf;
|
|
|
|
|
2013-09-13 02:10:25 +08:00
|
|
|
trace_get_random_bytes_arch(nbytes, _RET_IP_);
|
2011-08-01 04:54:50 +08:00
|
|
|
while (nbytes) {
|
|
|
|
unsigned long v;
|
|
|
|
int chunk = min(nbytes, (int)sizeof(unsigned long));
|
random: add new get_random_bytes_arch() function
Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present. Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.
The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door. (For example, an
increasing counter encrypted by an AES key known to the NSA.)
It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
--- especially since Bull Mountain is documented to use AES as a
whitener. Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel. Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.
Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.
This way we get almost of the benefits of the HW RNG without any
potential liabilities. The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.
For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
2012-07-05 22:35:23 +08:00
|
|
|
|
2011-08-01 04:54:50 +08:00
|
|
|
if (!arch_get_random_long(&v))
|
|
|
|
break;
|
|
|
|
|
2011-11-17 02:50:56 +08:00
|
|
|
memcpy(p, &v, chunk);
|
2011-08-01 04:54:50 +08:00
|
|
|
p += chunk;
|
|
|
|
nbytes -= chunk;
|
|
|
|
}
|
|
|
|
|
random: add new get_random_bytes_arch() function
Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present. Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.
The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door. (For example, an
increasing counter encrypted by an AES key known to the NSA.)
It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
--- especially since Bull Mountain is documented to use AES as a
whitener. Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel. Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.
Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.
This way we get almost of the benefits of the HW RNG without any
potential liabilities. The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.
For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
2012-07-05 22:35:23 +08:00
|
|
|
if (nbytes)
|
2016-06-13 06:13:36 +08:00
|
|
|
get_random_bytes(p, nbytes);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
random: add new get_random_bytes_arch() function
Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present. Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.
The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door. (For example, an
increasing counter encrypted by an AES key known to the NSA.)
It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise
--- especially since Bull Mountain is documented to use AES as a
whitener. Hence, the output of an evil, trojan-horse version of
RDRAND is statistically indistinguishable from an RDRAND implemented
to the specifications claimed by Intel. Short of using a tunnelling
electronic microscope to reverse engineer an Ivy Bridge chip and
disassembling and analyzing the CPU microcode, there's no way for us
to tell for sure.
Since users of get_random_bytes() in the Linux kernel need to be able
to support hardware systems where the HW RNG is not present, most
time-sensitive users of this interface have already created their own
cryptographic RNG interface which uses get_random_bytes() as a seed.
So it's much better to use the HW RNG to improve the existing random
number generator, by mixing in any entropy returned by the HW RNG into
/dev/random's entropy pool, but to always _use_ /dev/random's entropy
pool.
This way we get almost of the benefits of the HW RNG without any
potential liabilities. The only benefits we forgo is the
speed/performance enhancements --- and generic kernel code can't
depend on depend on get_random_bytes() having the speed of a HW RNG
anyway.
For those places that really want access to the arch-specific HW RNG,
if it is available, we provide get_random_bytes_arch().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
2012-07-05 22:35:23 +08:00
|
|
|
EXPORT_SYMBOL(get_random_bytes_arch);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* init_std_data - initialize pool with system data
|
|
|
|
*
|
|
|
|
* @r: pool to initialize
|
|
|
|
*
|
|
|
|
* This function clears the pool's entropy count and mixes some system
|
|
|
|
* data into the pool to prepare it for use. The pool is not cleared
|
|
|
|
* as that can only decrease the entropy in the pool.
|
|
|
|
*/
|
|
|
|
static void init_std_data(struct entropy_store *r)
|
|
|
|
{
|
2011-12-23 05:28:01 +08:00
|
|
|
int i;
|
2012-07-04 22:38:30 +08:00
|
|
|
ktime_t now = ktime_get_real();
|
|
|
|
unsigned long rv;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-09-23 03:14:32 +08:00
|
|
|
r->last_pulled = jiffies;
|
2014-06-11 11:09:20 +08:00
|
|
|
mix_pool_bytes(r, &now, sizeof(now));
|
2013-09-11 11:16:17 +08:00
|
|
|
for (i = r->poolinfo->poolbytes; i > 0; i -= sizeof(rv)) {
|
2014-03-18 07:36:28 +08:00
|
|
|
if (!arch_get_random_seed_long(&rv) &&
|
|
|
|
!arch_get_random_long(&rv))
|
2013-11-03 20:56:17 +08:00
|
|
|
rv = random_get_entropy();
|
2014-06-11 11:09:20 +08:00
|
|
|
mix_pool_bytes(r, &rv, sizeof(rv));
|
2011-12-23 05:28:01 +08:00
|
|
|
}
|
2014-06-11 11:09:20 +08:00
|
|
|
mix_pool_bytes(r, utsname(), sizeof(*(utsname())));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2012-07-24 00:47:57 +08:00
|
|
|
/*
|
|
|
|
* Note that setup_arch() may call add_device_randomness()
|
|
|
|
* long before we get here. This allows seeding of the pools
|
|
|
|
* with some platform dependent data very early in the boot
|
|
|
|
* process. But it limits our options here. We must use
|
|
|
|
* statically allocated structures that already have all
|
|
|
|
* initializations complete at compile time. We should also
|
|
|
|
* take care not to overwrite the precious per platform data
|
|
|
|
* we were given.
|
|
|
|
*/
|
2008-04-29 16:02:58 +08:00
|
|
|
static int rand_initialize(void)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
init_std_data(&input_pool);
|
|
|
|
init_std_data(&blocking_pool);
|
2016-06-13 06:13:36 +08:00
|
|
|
crng_initialize(&primary_crng);
|
2018-04-12 04:32:17 +08:00
|
|
|
crng_global_init_time = jiffies;
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2013-11-03 20:56:17 +08:00
|
|
|
early_initcall(rand_initialize);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
[PATCH] BLOCK: Make it possible to disable the block layer [try #6]
Make it possible to disable the block layer. Not all embedded devices require
it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
the block layer to be present.
This patch does the following:
(*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
support.
(*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
an item that uses the block layer. This includes:
(*) Block I/O tracing.
(*) Disk partition code.
(*) All filesystems that are block based, eg: Ext3, ReiserFS, ISOFS.
(*) The SCSI layer. As far as I can tell, even SCSI chardevs use the
block layer to do scheduling. Some drivers that use SCSI facilities -
such as USB storage - end up disabled indirectly from this.
(*) Various block-based device drivers, such as IDE and the old CDROM
drivers.
(*) MTD blockdev handling and FTL.
(*) JFFS - which uses set_bdev_super(), something it could avoid doing by
taking a leaf out of JFFS2's book.
(*) Makes most of the contents of linux/blkdev.h, linux/buffer_head.h and
linux/elevator.h contingent on CONFIG_BLOCK being set. sector_div() is,
however, still used in places, and so is still available.
(*) Also made contingent are the contents of linux/mpage.h, linux/genhd.h and
parts of linux/fs.h.
(*) Makes a number of files in fs/ contingent on CONFIG_BLOCK.
(*) Makes mm/bounce.c (bounce buffering) contingent on CONFIG_BLOCK.
(*) set_page_dirty() doesn't call __set_page_dirty_buffers() if CONFIG_BLOCK
is not enabled.
(*) fs/no-block.c is created to hold out-of-line stubs and things that are
required when CONFIG_BLOCK is not set:
(*) Default blockdev file operations (to give error ENODEV on opening).
(*) Makes some /proc changes:
(*) /proc/devices does not list any blockdevs.
(*) /proc/diskstats and /proc/partitions are contingent on CONFIG_BLOCK.
(*) Makes some compat ioctl handling contingent on CONFIG_BLOCK.
(*) If CONFIG_BLOCK is not defined, makes sys_quotactl() return -ENODEV if
given command other than Q_SYNC or if a special device is specified.
(*) In init/do_mounts.c, no reference is made to the blockdev routines if
CONFIG_BLOCK is not defined. This does not prohibit NFS roots or JFFS2.
(*) The bdflush, ioprio_set and ioprio_get syscalls can now be absent (return
error ENOSYS by way of cond_syscall if so).
(*) The seclvl_bd_claim() and seclvl_bd_release() security calls do nothing if
CONFIG_BLOCK is not set, since they can't then happen.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2006-10-01 02:45:40 +08:00
|
|
|
#ifdef CONFIG_BLOCK
|
2005-04-17 06:20:36 +08:00
|
|
|
void rand_initialize_disk(struct gendisk *disk)
|
|
|
|
{
|
|
|
|
struct timer_rand_state *state;
|
|
|
|
|
|
|
|
/*
|
2007-03-29 05:22:33 +08:00
|
|
|
* If kzalloc returns null, we just won't use that entropy
|
2005-04-17 06:20:36 +08:00
|
|
|
* source.
|
|
|
|
*/
|
2007-03-29 05:22:33 +08:00
|
|
|
state = kzalloc(sizeof(struct timer_rand_state), GFP_KERNEL);
|
2013-11-04 05:40:53 +08:00
|
|
|
if (state) {
|
|
|
|
state->last_time = INITIAL_JIFFIES;
|
2005-04-17 06:20:36 +08:00
|
|
|
disk->random = state;
|
2013-11-04 05:40:53 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
[PATCH] BLOCK: Make it possible to disable the block layer [try #6]
Make it possible to disable the block layer. Not all embedded devices require
it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
the block layer to be present.
This patch does the following:
(*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
support.
(*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
an item that uses the block layer. This includes:
(*) Block I/O tracing.
(*) Disk partition code.
(*) All filesystems that are block based, eg: Ext3, ReiserFS, ISOFS.
(*) The SCSI layer. As far as I can tell, even SCSI chardevs use the
block layer to do scheduling. Some drivers that use SCSI facilities -
such as USB storage - end up disabled indirectly from this.
(*) Various block-based device drivers, such as IDE and the old CDROM
drivers.
(*) MTD blockdev handling and FTL.
(*) JFFS - which uses set_bdev_super(), something it could avoid doing by
taking a leaf out of JFFS2's book.
(*) Makes most of the contents of linux/blkdev.h, linux/buffer_head.h and
linux/elevator.h contingent on CONFIG_BLOCK being set. sector_div() is,
however, still used in places, and so is still available.
(*) Also made contingent are the contents of linux/mpage.h, linux/genhd.h and
parts of linux/fs.h.
(*) Makes a number of files in fs/ contingent on CONFIG_BLOCK.
(*) Makes mm/bounce.c (bounce buffering) contingent on CONFIG_BLOCK.
(*) set_page_dirty() doesn't call __set_page_dirty_buffers() if CONFIG_BLOCK
is not enabled.
(*) fs/no-block.c is created to hold out-of-line stubs and things that are
required when CONFIG_BLOCK is not set:
(*) Default blockdev file operations (to give error ENODEV on opening).
(*) Makes some /proc changes:
(*) /proc/devices does not list any blockdevs.
(*) /proc/diskstats and /proc/partitions are contingent on CONFIG_BLOCK.
(*) Makes some compat ioctl handling contingent on CONFIG_BLOCK.
(*) If CONFIG_BLOCK is not defined, makes sys_quotactl() return -ENODEV if
given command other than Q_SYNC or if a special device is specified.
(*) In init/do_mounts.c, no reference is made to the blockdev routines if
CONFIG_BLOCK is not defined. This does not prohibit NFS roots or JFFS2.
(*) The bdflush, ioprio_set and ioprio_get syscalls can now be absent (return
error ENOSYS by way of cond_syscall if so).
(*) The seclvl_bd_claim() and seclvl_bd_release() security calls do nothing if
CONFIG_BLOCK is not set, since they can't then happen.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2006-10-01 02:45:40 +08:00
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
static ssize_t
|
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
2014-07-17 16:13:05 +08:00
|
|
|
_random_read(int nonblock, char __user *buf, size_t nbytes)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2013-11-30 04:02:33 +08:00
|
|
|
ssize_t n;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (nbytes == 0)
|
|
|
|
return 0;
|
|
|
|
|
2013-11-30 04:02:33 +08:00
|
|
|
nbytes = min_t(size_t, nbytes, SEC_XFER_SIZE);
|
|
|
|
while (1) {
|
|
|
|
n = extract_entropy_user(&blocking_pool, buf, nbytes);
|
|
|
|
if (n < 0)
|
|
|
|
return n;
|
2013-10-04 00:02:37 +08:00
|
|
|
trace_random_read(n*8, (nbytes-n)*8,
|
|
|
|
ENTROPY_BITS(&blocking_pool),
|
|
|
|
ENTROPY_BITS(&input_pool));
|
2013-11-30 04:02:33 +08:00
|
|
|
if (n > 0)
|
|
|
|
return n;
|
2014-03-18 07:36:29 +08:00
|
|
|
|
2013-11-30 04:02:33 +08:00
|
|
|
/* Pool is (near) empty. Maybe wait and retry. */
|
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
2014-07-17 16:13:05 +08:00
|
|
|
if (nonblock)
|
2013-11-30 04:02:33 +08:00
|
|
|
return -EAGAIN;
|
|
|
|
|
|
|
|
wait_event_interruptible(random_read_wait,
|
|
|
|
ENTROPY_BITS(&input_pool) >=
|
2013-12-07 10:28:03 +08:00
|
|
|
random_read_wakeup_bits);
|
2013-11-30 04:02:33 +08:00
|
|
|
if (signal_pending(current))
|
|
|
|
return -ERESTARTSYS;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
2014-07-17 16:13:05 +08:00
|
|
|
static ssize_t
|
|
|
|
random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
|
|
|
|
{
|
|
|
|
return _random_read(file->f_flags & O_NONBLOCK, buf, nbytes);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static ssize_t
|
2008-04-29 16:02:55 +08:00
|
|
|
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2016-06-13 06:13:36 +08:00
|
|
|
unsigned long flags;
|
2016-06-13 22:10:51 +08:00
|
|
|
static int maxwarn = 10;
|
2013-11-03 19:54:51 +08:00
|
|
|
int ret;
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
if (!crng_ready() && maxwarn > 0) {
|
2016-06-13 22:10:51 +08:00
|
|
|
maxwarn--;
|
|
|
|
printk(KERN_NOTICE "random: %s: uninitialized urandom read "
|
2016-06-13 06:13:36 +08:00
|
|
|
"(%zd bytes read)\n",
|
|
|
|
current->comm, nbytes);
|
|
|
|
spin_lock_irqsave(&primary_crng.lock, flags);
|
|
|
|
crng_init_cnt = 0;
|
|
|
|
spin_unlock_irqrestore(&primary_crng.lock, flags);
|
2016-06-13 22:10:51 +08:00
|
|
|
}
|
2014-07-19 05:26:41 +08:00
|
|
|
nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
|
2016-06-13 06:13:36 +08:00
|
|
|
ret = extract_crng_user(buf, nbytes);
|
|
|
|
trace_urandom_read(8 * nbytes, 0, ENTROPY_BITS(&input_pool));
|
2013-10-04 00:02:37 +08:00
|
|
|
return ret;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2017-07-03 18:39:46 +08:00
|
|
|
static __poll_t
|
2005-04-17 06:20:36 +08:00
|
|
|
random_poll(struct file *file, poll_table * wait)
|
|
|
|
{
|
2017-07-03 18:39:46 +08:00
|
|
|
__poll_t mask;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
poll_wait(file, &random_read_wait, wait);
|
|
|
|
poll_wait(file, &random_write_wait, wait);
|
|
|
|
mask = 0;
|
2013-12-07 10:28:03 +08:00
|
|
|
if (ENTROPY_BITS(&input_pool) >= random_read_wakeup_bits)
|
2018-02-12 06:34:03 +08:00
|
|
|
mask |= EPOLLIN | EPOLLRDNORM;
|
2013-12-07 10:28:03 +08:00
|
|
|
if (ENTROPY_BITS(&input_pool) < random_write_wakeup_bits)
|
2018-02-12 06:34:03 +08:00
|
|
|
mask |= EPOLLOUT | EPOLLWRNORM;
|
2005-04-17 06:20:36 +08:00
|
|
|
return mask;
|
|
|
|
}
|
|
|
|
|
2007-05-30 10:58:10 +08:00
|
|
|
static int
|
|
|
|
write_pool(struct entropy_store *r, const char __user *buffer, size_t count)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
size_t bytes;
|
|
|
|
__u32 buf[16];
|
|
|
|
const char __user *p = buffer;
|
|
|
|
|
2007-05-30 10:58:10 +08:00
|
|
|
while (count > 0) {
|
|
|
|
bytes = min(count, sizeof(buf));
|
|
|
|
if (copy_from_user(&buf, p, bytes))
|
|
|
|
return -EFAULT;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-05-30 10:58:10 +08:00
|
|
|
count -= bytes;
|
2005-04-17 06:20:36 +08:00
|
|
|
p += bytes;
|
|
|
|
|
2014-06-11 11:09:20 +08:00
|
|
|
mix_pool_bytes(r, buf, bytes);
|
2008-02-06 17:37:20 +08:00
|
|
|
cond_resched();
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2007-05-30 10:58:10 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-04-29 16:02:55 +08:00
|
|
|
static ssize_t random_write(struct file *file, const char __user *buffer,
|
|
|
|
size_t count, loff_t *ppos)
|
2007-05-30 10:58:10 +08:00
|
|
|
{
|
|
|
|
size_t ret;
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
ret = write_pool(&input_pool, buffer, count);
|
2007-05-30 10:58:10 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
return (ssize_t)count;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2008-04-29 16:02:58 +08:00
|
|
|
static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int size, ent_count;
|
|
|
|
int __user *p = (int __user *)arg;
|
|
|
|
int retval;
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case RNDGETENTCNT:
|
2008-04-29 16:02:58 +08:00
|
|
|
/* inherently racy, no point locking */
|
2013-09-11 11:16:17 +08:00
|
|
|
ent_count = ENTROPY_BITS(&input_pool);
|
|
|
|
if (put_user(ent_count, p))
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EFAULT;
|
|
|
|
return 0;
|
|
|
|
case RNDADDTOENTCNT:
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
if (get_user(ent_count, p))
|
|
|
|
return -EFAULT;
|
2016-07-04 05:01:26 +08:00
|
|
|
return credit_entropy_bits_safe(&input_pool, ent_count);
|
2005-04-17 06:20:36 +08:00
|
|
|
case RNDADDENTROPY:
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
if (get_user(ent_count, p++))
|
|
|
|
return -EFAULT;
|
|
|
|
if (ent_count < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
if (get_user(size, p++))
|
|
|
|
return -EFAULT;
|
2007-05-30 10:58:10 +08:00
|
|
|
retval = write_pool(&input_pool, (const char __user *)p,
|
|
|
|
size);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (retval < 0)
|
|
|
|
return retval;
|
2016-07-04 05:01:26 +08:00
|
|
|
return credit_entropy_bits_safe(&input_pool, ent_count);
|
2005-04-17 06:20:36 +08:00
|
|
|
case RNDZAPENTCNT:
|
|
|
|
case RNDCLEARPOOL:
|
2013-11-03 20:56:17 +08:00
|
|
|
/*
|
|
|
|
* Clear the entropy pool counters. We no longer clear
|
|
|
|
* the entropy pool, as that's silly.
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
2013-11-03 20:56:17 +08:00
|
|
|
input_pool.entropy_count = 0;
|
|
|
|
blocking_pool.entropy_count = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
2018-04-12 04:32:17 +08:00
|
|
|
case RNDRESEEDCRNG:
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
if (crng_init < 2)
|
|
|
|
return -ENODATA;
|
|
|
|
crng_reseed(&primary_crng, NULL);
|
|
|
|
crng_global_init_time = jiffies - 1;
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
random: add async notification support to /dev/random
Add async notification support to /dev/random.
A little test case is below. Without this patch, you get:
$ ./async-random
Drained the pool
Found more randomness
With it, you get:
$ ./async-random
Drained the pool
SIGIO
Found more randomness
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <errno.h>
#include <fcntl.h>
static void handler(int sig)
{
printf("SIGIO\n");
}
int main(int argc, char **argv)
{
int fd, n, err, flags;
if(signal(SIGIO, handler) < 0){
perror("setting SIGIO handler");
exit(1);
}
fd = open("/dev/random", O_RDONLY);
if(fd < 0){
perror("open");
exit(1);
}
flags = fcntl(fd, F_GETFL);
if (flags < 0){
perror("getting flags");
exit(1);
}
flags |= O_NONBLOCK;
if (fcntl(fd, F_SETFL, flags) < 0){
perror("setting flags");
exit(1);
}
while((err = read(fd, &n, sizeof(n))) > 0) ;
if(err == 0){
printf("random returned 0\n");
exit(1);
}
else if(errno != EAGAIN){
perror("read");
exit(1);
}
flags |= O_ASYNC;
if (fcntl(fd, F_SETFL, flags) < 0){
perror("setting flags");
exit(1);
}
if (fcntl(fd, F_SETOWN, getpid()) < 0) {
perror("Setting SIGIO");
exit(1);
}
printf("Drained the pool\n");
read(fd, &n, sizeof(n));
printf("Found more randomness\n");
return(0);
}
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Matt Mackall <mpm@selenic.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-29 16:03:08 +08:00
|
|
|
static int random_fasync(int fd, struct file *filp, int on)
|
|
|
|
{
|
|
|
|
return fasync_helper(fd, filp, on, &fasync);
|
|
|
|
}
|
|
|
|
|
2007-02-12 16:55:32 +08:00
|
|
|
const struct file_operations random_fops = {
|
2005-04-17 06:20:36 +08:00
|
|
|
.read = random_read,
|
|
|
|
.write = random_write,
|
|
|
|
.poll = random_poll,
|
2008-04-29 16:02:58 +08:00
|
|
|
.unlocked_ioctl = random_ioctl,
|
random: add async notification support to /dev/random
Add async notification support to /dev/random.
A little test case is below. Without this patch, you get:
$ ./async-random
Drained the pool
Found more randomness
With it, you get:
$ ./async-random
Drained the pool
SIGIO
Found more randomness
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <errno.h>
#include <fcntl.h>
static void handler(int sig)
{
printf("SIGIO\n");
}
int main(int argc, char **argv)
{
int fd, n, err, flags;
if(signal(SIGIO, handler) < 0){
perror("setting SIGIO handler");
exit(1);
}
fd = open("/dev/random", O_RDONLY);
if(fd < 0){
perror("open");
exit(1);
}
flags = fcntl(fd, F_GETFL);
if (flags < 0){
perror("getting flags");
exit(1);
}
flags |= O_NONBLOCK;
if (fcntl(fd, F_SETFL, flags) < 0){
perror("setting flags");
exit(1);
}
while((err = read(fd, &n, sizeof(n))) > 0) ;
if(err == 0){
printf("random returned 0\n");
exit(1);
}
else if(errno != EAGAIN){
perror("read");
exit(1);
}
flags |= O_ASYNC;
if (fcntl(fd, F_SETFL, flags) < 0){
perror("setting flags");
exit(1);
}
if (fcntl(fd, F_SETOWN, getpid()) < 0) {
perror("Setting SIGIO");
exit(1);
}
printf("Drained the pool\n");
read(fd, &n, sizeof(n));
printf("Found more randomness\n");
return(0);
}
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Matt Mackall <mpm@selenic.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-29 16:03:08 +08:00
|
|
|
.fasync = random_fasync,
|
llseek: automatically add .llseek fop
All file_operations should get a .llseek operation so we can make
nonseekable_open the default for future file operations without a
.llseek pointer.
The three cases that we can automatically detect are no_llseek, seq_lseek
and default_llseek. For cases where we can we can automatically prove that
the file offset is always ignored, we use noop_llseek, which maintains
the current behavior of not returning an error from a seek.
New drivers should normally not use noop_llseek but instead use no_llseek
and call nonseekable_open at open time. Existing drivers can be converted
to do the same when the maintainer knows for certain that no user code
relies on calling seek on the device file.
The generated code is often incorrectly indented and right now contains
comments that clarify for each added line why a specific variant was
chosen. In the version that gets submitted upstream, the comments will
be gone and I will manually fix the indentation, because there does not
seem to be a way to do that using coccinelle.
Some amount of new code is currently sitting in linux-next that should get
the same modifications, which I will do at the end of the merge window.
Many thanks to Julia Lawall for helping me learn to write a semantic
patch that does all this.
===== begin semantic patch =====
// This adds an llseek= method to all file operations,
// as a preparation for making no_llseek the default.
//
// The rules are
// - use no_llseek explicitly if we do nonseekable_open
// - use seq_lseek for sequential files
// - use default_llseek if we know we access f_pos
// - use noop_llseek if we know we don't access f_pos,
// but we still want to allow users to call lseek
//
@ open1 exists @
identifier nested_open;
@@
nested_open(...)
{
<+...
nonseekable_open(...)
...+>
}
@ open exists@
identifier open_f;
identifier i, f;
identifier open1.nested_open;
@@
int open_f(struct inode *i, struct file *f)
{
<+...
(
nonseekable_open(...)
|
nested_open(...)
)
...+>
}
@ read disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
<+...
(
*off = E
|
*off += E
|
func(..., off, ...)
|
E = *off
)
...+>
}
@ read_no_fpos disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
... when != off
}
@ write @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
<+...
(
*off = E
|
*off += E
|
func(..., off, ...)
|
E = *off
)
...+>
}
@ write_no_fpos @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
... when != off
}
@ fops0 @
identifier fops;
@@
struct file_operations fops = {
...
};
@ has_llseek depends on fops0 @
identifier fops0.fops;
identifier llseek_f;
@@
struct file_operations fops = {
...
.llseek = llseek_f,
...
};
@ has_read depends on fops0 @
identifier fops0.fops;
identifier read_f;
@@
struct file_operations fops = {
...
.read = read_f,
...
};
@ has_write depends on fops0 @
identifier fops0.fops;
identifier write_f;
@@
struct file_operations fops = {
...
.write = write_f,
...
};
@ has_open depends on fops0 @
identifier fops0.fops;
identifier open_f;
@@
struct file_operations fops = {
...
.open = open_f,
...
};
// use no_llseek if we call nonseekable_open
////////////////////////////////////////////
@ nonseekable1 depends on !has_llseek && has_open @
identifier fops0.fops;
identifier nso ~= "nonseekable_open";
@@
struct file_operations fops = {
... .open = nso, ...
+.llseek = no_llseek, /* nonseekable */
};
@ nonseekable2 depends on !has_llseek @
identifier fops0.fops;
identifier open.open_f;
@@
struct file_operations fops = {
... .open = open_f, ...
+.llseek = no_llseek, /* open uses nonseekable */
};
// use seq_lseek for sequential files
/////////////////////////////////////
@ seq depends on !has_llseek @
identifier fops0.fops;
identifier sr ~= "seq_read";
@@
struct file_operations fops = {
... .read = sr, ...
+.llseek = seq_lseek, /* we have seq_read */
};
// use default_llseek if there is a readdir
///////////////////////////////////////////
@ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier readdir_e;
@@
// any other fop is used that changes pos
struct file_operations fops = {
... .readdir = readdir_e, ...
+.llseek = default_llseek, /* readdir is present */
};
// use default_llseek if at least one of read/write touches f_pos
/////////////////////////////////////////////////////////////////
@ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read.read_f;
@@
// read fops use offset
struct file_operations fops = {
... .read = read_f, ...
+.llseek = default_llseek, /* read accesses f_pos */
};
@ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write.write_f;
@@
// write fops use offset
struct file_operations fops = {
... .write = write_f, ...
+ .llseek = default_llseek, /* write accesses f_pos */
};
// Use noop_llseek if neither read nor write accesses f_pos
///////////////////////////////////////////////////////////
@ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
identifier write_no_fpos.write_f;
@@
// write fops use offset
struct file_operations fops = {
...
.write = write_f,
.read = read_f,
...
+.llseek = noop_llseek, /* read and write both use no f_pos */
};
@ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write_no_fpos.write_f;
@@
struct file_operations fops = {
... .write = write_f, ...
+.llseek = noop_llseek, /* write uses no f_pos */
};
@ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
@@
struct file_operations fops = {
... .read = read_f, ...
+.llseek = noop_llseek, /* read uses no f_pos */
};
@ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
@@
struct file_operations fops = {
...
+.llseek = noop_llseek, /* no read or write fn */
};
===== End semantic patch =====
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Julia Lawall <julia@diku.dk>
Cc: Christoph Hellwig <hch@infradead.org>
2010-08-16 00:52:59 +08:00
|
|
|
.llseek = noop_llseek,
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2007-02-12 16:55:32 +08:00
|
|
|
const struct file_operations urandom_fops = {
|
2005-04-17 06:20:36 +08:00
|
|
|
.read = urandom_read,
|
|
|
|
.write = random_write,
|
2008-04-29 16:02:58 +08:00
|
|
|
.unlocked_ioctl = random_ioctl,
|
random: add async notification support to /dev/random
Add async notification support to /dev/random.
A little test case is below. Without this patch, you get:
$ ./async-random
Drained the pool
Found more randomness
With it, you get:
$ ./async-random
Drained the pool
SIGIO
Found more randomness
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <errno.h>
#include <fcntl.h>
static void handler(int sig)
{
printf("SIGIO\n");
}
int main(int argc, char **argv)
{
int fd, n, err, flags;
if(signal(SIGIO, handler) < 0){
perror("setting SIGIO handler");
exit(1);
}
fd = open("/dev/random", O_RDONLY);
if(fd < 0){
perror("open");
exit(1);
}
flags = fcntl(fd, F_GETFL);
if (flags < 0){
perror("getting flags");
exit(1);
}
flags |= O_NONBLOCK;
if (fcntl(fd, F_SETFL, flags) < 0){
perror("setting flags");
exit(1);
}
while((err = read(fd, &n, sizeof(n))) > 0) ;
if(err == 0){
printf("random returned 0\n");
exit(1);
}
else if(errno != EAGAIN){
perror("read");
exit(1);
}
flags |= O_ASYNC;
if (fcntl(fd, F_SETFL, flags) < 0){
perror("setting flags");
exit(1);
}
if (fcntl(fd, F_SETOWN, getpid()) < 0) {
perror("Setting SIGIO");
exit(1);
}
printf("Drained the pool\n");
read(fd, &n, sizeof(n));
printf("Found more randomness\n");
return(0);
}
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Matt Mackall <mpm@selenic.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-29 16:03:08 +08:00
|
|
|
.fasync = random_fasync,
|
llseek: automatically add .llseek fop
All file_operations should get a .llseek operation so we can make
nonseekable_open the default for future file operations without a
.llseek pointer.
The three cases that we can automatically detect are no_llseek, seq_lseek
and default_llseek. For cases where we can we can automatically prove that
the file offset is always ignored, we use noop_llseek, which maintains
the current behavior of not returning an error from a seek.
New drivers should normally not use noop_llseek but instead use no_llseek
and call nonseekable_open at open time. Existing drivers can be converted
to do the same when the maintainer knows for certain that no user code
relies on calling seek on the device file.
The generated code is often incorrectly indented and right now contains
comments that clarify for each added line why a specific variant was
chosen. In the version that gets submitted upstream, the comments will
be gone and I will manually fix the indentation, because there does not
seem to be a way to do that using coccinelle.
Some amount of new code is currently sitting in linux-next that should get
the same modifications, which I will do at the end of the merge window.
Many thanks to Julia Lawall for helping me learn to write a semantic
patch that does all this.
===== begin semantic patch =====
// This adds an llseek= method to all file operations,
// as a preparation for making no_llseek the default.
//
// The rules are
// - use no_llseek explicitly if we do nonseekable_open
// - use seq_lseek for sequential files
// - use default_llseek if we know we access f_pos
// - use noop_llseek if we know we don't access f_pos,
// but we still want to allow users to call lseek
//
@ open1 exists @
identifier nested_open;
@@
nested_open(...)
{
<+...
nonseekable_open(...)
...+>
}
@ open exists@
identifier open_f;
identifier i, f;
identifier open1.nested_open;
@@
int open_f(struct inode *i, struct file *f)
{
<+...
(
nonseekable_open(...)
|
nested_open(...)
)
...+>
}
@ read disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
<+...
(
*off = E
|
*off += E
|
func(..., off, ...)
|
E = *off
)
...+>
}
@ read_no_fpos disable optional_qualifier exists @
identifier read_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t read_f(struct file *f, char *p, size_t s, loff_t *off)
{
... when != off
}
@ write @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
expression E;
identifier func;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
<+...
(
*off = E
|
*off += E
|
func(..., off, ...)
|
E = *off
)
...+>
}
@ write_no_fpos @
identifier write_f;
identifier f, p, s, off;
type ssize_t, size_t, loff_t;
@@
ssize_t write_f(struct file *f, const char *p, size_t s, loff_t *off)
{
... when != off
}
@ fops0 @
identifier fops;
@@
struct file_operations fops = {
...
};
@ has_llseek depends on fops0 @
identifier fops0.fops;
identifier llseek_f;
@@
struct file_operations fops = {
...
.llseek = llseek_f,
...
};
@ has_read depends on fops0 @
identifier fops0.fops;
identifier read_f;
@@
struct file_operations fops = {
...
.read = read_f,
...
};
@ has_write depends on fops0 @
identifier fops0.fops;
identifier write_f;
@@
struct file_operations fops = {
...
.write = write_f,
...
};
@ has_open depends on fops0 @
identifier fops0.fops;
identifier open_f;
@@
struct file_operations fops = {
...
.open = open_f,
...
};
// use no_llseek if we call nonseekable_open
////////////////////////////////////////////
@ nonseekable1 depends on !has_llseek && has_open @
identifier fops0.fops;
identifier nso ~= "nonseekable_open";
@@
struct file_operations fops = {
... .open = nso, ...
+.llseek = no_llseek, /* nonseekable */
};
@ nonseekable2 depends on !has_llseek @
identifier fops0.fops;
identifier open.open_f;
@@
struct file_operations fops = {
... .open = open_f, ...
+.llseek = no_llseek, /* open uses nonseekable */
};
// use seq_lseek for sequential files
/////////////////////////////////////
@ seq depends on !has_llseek @
identifier fops0.fops;
identifier sr ~= "seq_read";
@@
struct file_operations fops = {
... .read = sr, ...
+.llseek = seq_lseek, /* we have seq_read */
};
// use default_llseek if there is a readdir
///////////////////////////////////////////
@ fops1 depends on !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier readdir_e;
@@
// any other fop is used that changes pos
struct file_operations fops = {
... .readdir = readdir_e, ...
+.llseek = default_llseek, /* readdir is present */
};
// use default_llseek if at least one of read/write touches f_pos
/////////////////////////////////////////////////////////////////
@ fops2 depends on !fops1 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read.read_f;
@@
// read fops use offset
struct file_operations fops = {
... .read = read_f, ...
+.llseek = default_llseek, /* read accesses f_pos */
};
@ fops3 depends on !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write.write_f;
@@
// write fops use offset
struct file_operations fops = {
... .write = write_f, ...
+ .llseek = default_llseek, /* write accesses f_pos */
};
// Use noop_llseek if neither read nor write accesses f_pos
///////////////////////////////////////////////////////////
@ fops4 depends on !fops1 && !fops2 && !fops3 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
identifier write_no_fpos.write_f;
@@
// write fops use offset
struct file_operations fops = {
...
.write = write_f,
.read = read_f,
...
+.llseek = noop_llseek, /* read and write both use no f_pos */
};
@ depends on has_write && !has_read && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier write_no_fpos.write_f;
@@
struct file_operations fops = {
... .write = write_f, ...
+.llseek = noop_llseek, /* write uses no f_pos */
};
@ depends on has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
identifier read_no_fpos.read_f;
@@
struct file_operations fops = {
... .read = read_f, ...
+.llseek = noop_llseek, /* read uses no f_pos */
};
@ depends on !has_read && !has_write && !fops1 && !fops2 && !has_llseek && !nonseekable1 && !nonseekable2 && !seq @
identifier fops0.fops;
@@
struct file_operations fops = {
...
+.llseek = noop_llseek, /* no read or write fn */
};
===== End semantic patch =====
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Julia Lawall <julia@diku.dk>
Cc: Christoph Hellwig <hch@infradead.org>
2010-08-16 00:52:59 +08:00
|
|
|
.llseek = noop_llseek,
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
2014-07-17 16:13:05 +08:00
|
|
|
SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
|
|
|
|
unsigned int, flags)
|
|
|
|
{
|
2017-06-08 07:58:56 +08:00
|
|
|
int ret;
|
|
|
|
|
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
2014-07-17 16:13:05 +08:00
|
|
|
if (flags & ~(GRND_NONBLOCK|GRND_RANDOM))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (count > INT_MAX)
|
|
|
|
count = INT_MAX;
|
|
|
|
|
|
|
|
if (flags & GRND_RANDOM)
|
|
|
|
return _random_read(flags & GRND_NONBLOCK, buf, count);
|
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
if (!crng_ready()) {
|
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
2014-07-17 16:13:05 +08:00
|
|
|
if (flags & GRND_NONBLOCK)
|
|
|
|
return -EAGAIN;
|
2017-06-08 07:58:56 +08:00
|
|
|
ret = wait_for_random_bytes();
|
|
|
|
if (unlikely(ret))
|
|
|
|
return ret;
|
random: introduce getrandom(2) system call
The getrandom(2) system call was requested by the LibreSSL Portable
developers. It is analoguous to the getentropy(2) system call in
OpenBSD.
The rationale of this system call is to provide resiliance against
file descriptor exhaustion attacks, where the attacker consumes all
available file descriptors, forcing the use of the fallback code where
/dev/[u]random is not available. Since the fallback code is often not
well-tested, it is better to eliminate this potential failure mode
entirely.
The other feature provided by this new system call is the ability to
request randomness from the /dev/urandom entropy pool, but to block
until at least 128 bits of entropy has been accumulated in the
/dev/urandom entropy pool. Historically, the emphasis in the
/dev/urandom development has been to ensure that urandom pool is
initialized as quickly as possible after system boot, and preferably
before the init scripts start execution.
This is because changing /dev/urandom reads to block represents an
interface change that could potentially break userspace which is not
acceptable. In practice, on most x86 desktop and server systems, in
general the entropy pool can be initialized before it is needed (and
in modern kernels, we will printk a warning message if not). However,
on an embedded system, this may not be the case. And so with this new
interface, we can provide the functionality of blocking until the
urandom pool has been initialized. Any userspace program which uses
this new functionality must take care to assure that if it is used
during the boot process, that it will not cause the init scripts or
other portions of the system startup to hang indefinitely.
SYNOPSIS
#include <linux/random.h>
int getrandom(void *buf, size_t buflen, unsigned int flags);
DESCRIPTION
The system call getrandom() fills the buffer pointed to by buf
with up to buflen random bytes which can be used to seed user
space random number generators (i.e., DRBG's) or for other
cryptographic uses. It should not be used for Monte Carlo
simulations or other programs/algorithms which are doing
probabilistic sampling.
If the GRND_RANDOM flags bit is set, then draw from the
/dev/random pool instead of the /dev/urandom pool. The
/dev/random pool is limited based on the entropy that can be
obtained from environmental noise, so if there is insufficient
entropy, the requested number of bytes may not be returned.
If there is no entropy available at all, getrandom(2) will
either block, or return an error with errno set to EAGAIN if
the GRND_NONBLOCK bit is set in flags.
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
The getentropy(2) system call in OpenBSD can be emulated using
the following function:
int getentropy(void *buf, size_t buflen)
{
int ret;
if (buflen > 256)
goto failure;
ret = getrandom(buf, buflen, 0);
if (ret < 0)
return ret;
if (ret == buflen)
return 0;
failure:
errno = EIO;
return -1;
}
RETURN VALUE
On success, the number of bytes that was filled in the buf is
returned. This may not be all the bytes requested by the
caller via buflen if insufficient entropy was present in the
/dev/random pool, or if the system call was interrupted by a
signal.
On error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid flag was passed to getrandom(2)
EFAULT buf is outside the accessible address space.
EAGAIN The requested entropy was not available, and
getentropy(2) would have blocked if the
GRND_NONBLOCK flag was not set.
EINTR While blocked waiting for entropy, the call was
interrupted by a signal handler; see the description
of how interrupted read(2) calls on "slow" devices
are handled with and without the SA_RESTART flag
in the signal(7) man page.
NOTES
For small requests (buflen <= 256) getrandom(2) will not
return EINTR when reading from the urandom pool once the
entropy pool has been initialized, and it will return all of
the bytes that have been requested. This is the recommended
way to use getrandom(2), and is designed for compatibility
with OpenBSD's getentropy() system call.
However, if you are using GRND_RANDOM, then getrandom(2) may
block until the entropy accounting determines that sufficient
environmental noise has been gathered such that getrandom(2)
will be operating as a NRBG instead of a DRBG for those people
who are working in the NIST SP 800-90 regime. Since it may
block for a long time, these guarantees do *not* apply. The
user may want to interrupt a hanging process using a signal,
so blocking until all of the requested bytes are returned
would be unfriendly.
For this reason, the user of getrandom(2) MUST always check
the return value, in case it returns some error, or if fewer
bytes than requested was returned. In the case of
!GRND_RANDOM and small request, the latter should never
happen, but the careful userspace code (and all crypto code
should be careful) should check for this anyway!
Finally, unless you are doing long-term key generation (and
perhaps not even then), you probably shouldn't be using
GRND_RANDOM. The cryptographic algorithms used for
/dev/urandom are quite conservative, and so should be
sufficient for all purposes. The disadvantage of GRND_RANDOM
is that it can block, and the increased complexity required to
deal with partially fulfilled getrandom(2) requests.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Zach Brown <zab@zabbo.net>
2014-07-17 16:13:05 +08:00
|
|
|
}
|
|
|
|
return urandom_read(NULL, buf, count, NULL);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/********************************************************************
|
|
|
|
*
|
|
|
|
* Sysctl interface
|
|
|
|
*
|
|
|
|
********************************************************************/
|
|
|
|
|
|
|
|
#ifdef CONFIG_SYSCTL
|
|
|
|
|
|
|
|
#include <linux/sysctl.h>
|
|
|
|
|
|
|
|
static int min_read_thresh = 8, min_write_thresh;
|
2013-12-06 08:19:29 +08:00
|
|
|
static int max_read_thresh = OUTPUT_POOL_WORDS * 32;
|
2005-04-17 06:20:36 +08:00
|
|
|
static int max_write_thresh = INPUT_POOL_WORDS * 32;
|
2017-02-01 00:36:07 +08:00
|
|
|
static int random_min_urandom_seed = 60;
|
2005-04-17 06:20:36 +08:00
|
|
|
static char sysctl_bootid[16];
|
|
|
|
|
|
|
|
/*
|
2013-11-30 03:58:16 +08:00
|
|
|
* This function is used to return both the bootid UUID, and random
|
2005-04-17 06:20:36 +08:00
|
|
|
* UUID. The difference is in whether table->data is NULL; if it is,
|
|
|
|
* then a new UUID is generated and returned to the user.
|
|
|
|
*
|
2013-11-30 03:58:16 +08:00
|
|
|
* If the user accesses this via the proc interface, the UUID will be
|
|
|
|
* returned as an ASCII string in the standard UUID format; if via the
|
|
|
|
* sysctl system call, as 16 bytes of binary data.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2013-06-14 10:37:35 +08:00
|
|
|
static int proc_do_uuid(struct ctl_table *table, int write,
|
2005-04-17 06:20:36 +08:00
|
|
|
void __user *buffer, size_t *lenp, loff_t *ppos)
|
|
|
|
{
|
2013-06-14 10:37:35 +08:00
|
|
|
struct ctl_table fake_table;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned char buf[64], tmp_uuid[16], *uuid;
|
|
|
|
|
|
|
|
uuid = table->data;
|
|
|
|
if (!uuid) {
|
|
|
|
uuid = tmp_uuid;
|
|
|
|
generate_random_uuid(uuid);
|
2012-04-13 03:49:12 +08:00
|
|
|
} else {
|
|
|
|
static DEFINE_SPINLOCK(bootid_spinlock);
|
|
|
|
|
|
|
|
spin_lock(&bootid_spinlock);
|
|
|
|
if (!uuid[8])
|
|
|
|
generate_random_uuid(uuid);
|
|
|
|
spin_unlock(&bootid_spinlock);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-12-15 10:01:11 +08:00
|
|
|
sprintf(buf, "%pU", uuid);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
fake_table.data = buf;
|
|
|
|
fake_table.maxlen = sizeof(buf);
|
|
|
|
|
2009-09-24 06:57:19 +08:00
|
|
|
return proc_dostring(&fake_table, write, buffer, lenp, ppos);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-09-11 11:16:17 +08:00
|
|
|
/*
|
|
|
|
* Return entropy available scaled to integral bits
|
|
|
|
*/
|
2014-06-07 05:37:58 +08:00
|
|
|
static int proc_do_entropy(struct ctl_table *table, int write,
|
2013-09-11 11:16:17 +08:00
|
|
|
void __user *buffer, size_t *lenp, loff_t *ppos)
|
|
|
|
{
|
2014-06-07 05:37:58 +08:00
|
|
|
struct ctl_table fake_table;
|
2013-09-11 11:16:17 +08:00
|
|
|
int entropy_count;
|
|
|
|
|
|
|
|
entropy_count = *(int *)table->data >> ENTROPY_SHIFT;
|
|
|
|
|
|
|
|
fake_table.data = &entropy_count;
|
|
|
|
fake_table.maxlen = sizeof(entropy_count);
|
|
|
|
|
|
|
|
return proc_dointvec(&fake_table, write, buffer, lenp, ppos);
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static int sysctl_poolsize = INPUT_POOL_WORDS * 32;
|
2013-06-14 10:37:35 +08:00
|
|
|
extern struct ctl_table random_table[];
|
|
|
|
struct ctl_table random_table[] = {
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
.procname = "poolsize",
|
|
|
|
.data = &sysctl_poolsize,
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0444,
|
2009-11-16 19:11:48 +08:00
|
|
|
.proc_handler = proc_dointvec,
|
2005-04-17 06:20:36 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "entropy_avail",
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0444,
|
2013-09-11 11:16:17 +08:00
|
|
|
.proc_handler = proc_do_entropy,
|
2005-04-17 06:20:36 +08:00
|
|
|
.data = &input_pool.entropy_count,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "read_wakeup_threshold",
|
2013-12-07 10:28:03 +08:00
|
|
|
.data = &random_read_wakeup_bits,
|
2005-04-17 06:20:36 +08:00
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
2009-11-16 19:11:48 +08:00
|
|
|
.proc_handler = proc_dointvec_minmax,
|
2005-04-17 06:20:36 +08:00
|
|
|
.extra1 = &min_read_thresh,
|
|
|
|
.extra2 = &max_read_thresh,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "write_wakeup_threshold",
|
2013-12-07 10:28:03 +08:00
|
|
|
.data = &random_write_wakeup_bits,
|
2005-04-17 06:20:36 +08:00
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
2009-11-16 19:11:48 +08:00
|
|
|
.proc_handler = proc_dointvec_minmax,
|
2005-04-17 06:20:36 +08:00
|
|
|
.extra1 = &min_write_thresh,
|
|
|
|
.extra2 = &max_write_thresh,
|
|
|
|
},
|
2013-09-23 03:14:32 +08:00
|
|
|
{
|
|
|
|
.procname = "urandom_min_reseed_secs",
|
|
|
|
.data = &random_min_urandom_seed,
|
|
|
|
.maxlen = sizeof(int),
|
|
|
|
.mode = 0644,
|
|
|
|
.proc_handler = proc_dointvec,
|
|
|
|
},
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
.procname = "boot_id",
|
|
|
|
.data = &sysctl_bootid,
|
|
|
|
.maxlen = 16,
|
|
|
|
.mode = 0444,
|
2009-11-16 19:11:48 +08:00
|
|
|
.proc_handler = proc_do_uuid,
|
2005-04-17 06:20:36 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "uuid",
|
|
|
|
.maxlen = 16,
|
|
|
|
.mode = 0444,
|
2009-11-16 19:11:48 +08:00
|
|
|
.proc_handler = proc_do_uuid,
|
2005-04-17 06:20:36 +08:00
|
|
|
},
|
2014-06-15 09:43:13 +08:00
|
|
|
#ifdef ADD_INTERRUPT_BENCH
|
|
|
|
{
|
|
|
|
.procname = "add_interrupt_avg_cycles",
|
|
|
|
.data = &avg_cycles,
|
|
|
|
.maxlen = sizeof(avg_cycles),
|
|
|
|
.mode = 0444,
|
|
|
|
.proc_handler = proc_doulongvec_minmax,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.procname = "add_interrupt_avg_deviation",
|
|
|
|
.data = &avg_deviation,
|
|
|
|
.maxlen = sizeof(avg_deviation),
|
|
|
|
.mode = 0444,
|
|
|
|
.proc_handler = proc_doulongvec_minmax,
|
|
|
|
},
|
|
|
|
#endif
|
2009-11-06 06:34:02 +08:00
|
|
|
{ }
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
#endif /* CONFIG_SYSCTL */
|
|
|
|
|
random: use chacha20 for get_random_int/long
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.
We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.
Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.
Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-01-07 02:32:01 +08:00
|
|
|
struct batched_entropy {
|
|
|
|
union {
|
2017-01-22 23:34:08 +08:00
|
|
|
u64 entropy_u64[CHACHA20_BLOCK_SIZE / sizeof(u64)];
|
|
|
|
u32 entropy_u32[CHACHA20_BLOCK_SIZE / sizeof(u32)];
|
random: use chacha20 for get_random_int/long
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.
We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.
Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.
Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-01-07 02:32:01 +08:00
|
|
|
};
|
|
|
|
unsigned int position;
|
|
|
|
};
|
random: invalidate batched entropy after crng init
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
2017-06-08 07:45:31 +08:00
|
|
|
static rwlock_t batched_entropy_reset_lock = __RW_LOCK_UNLOCKED(batched_entropy_reset_lock);
|
2016-05-05 09:08:39 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
random: use chacha20 for get_random_int/long
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.
We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.
Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.
Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-01-07 02:32:01 +08:00
|
|
|
* Get a random word for internal kernel use only. The quality of the random
|
|
|
|
* number is either as good as RDRAND or as good as /dev/urandom, with the
|
2017-06-08 07:58:56 +08:00
|
|
|
* goal of being quite fast and not depleting entropy. In order to ensure
|
|
|
|
* that the randomness provided by this function is okay, the function
|
|
|
|
* wait_for_random_bytes() should be called and return 0 at least once
|
|
|
|
* at any point prior.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2017-01-22 23:34:08 +08:00
|
|
|
static DEFINE_PER_CPU(struct batched_entropy, batched_entropy_u64);
|
|
|
|
u64 get_random_u64(void)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2017-01-22 23:34:08 +08:00
|
|
|
u64 ret;
|
2017-06-30 22:37:13 +08:00
|
|
|
bool use_lock;
|
2017-06-15 06:45:26 +08:00
|
|
|
unsigned long flags = 0;
|
random: use chacha20 for get_random_int/long
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.
We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.
Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.
Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-01-07 02:32:01 +08:00
|
|
|
struct batched_entropy *batch;
|
2017-06-08 16:16:59 +08:00
|
|
|
static void *previous;
|
random: make get_random_int() more random
It's a really simple patch that basically just open-codes the current
"secure_ip_id()" call, but when open-coding it we now use a _static_
hashing area, so that it gets updated every time.
And to make sure somebody can't just start from the same original seed of
all-zeroes, and then do the "half_md4_transform()" over and over until
they get the same sequence as the kernel has, each iteration also mixes in
the same old "current->pid + jiffies" we used - so we should now have a
regular strong pseudo-number generator, but we also have one that doesn't
have a single seed.
Note: the "pid + jiffies" is just meant to be a tiny tiny bit of noise. It
has no real meaning. It could be anything. I just picked the previous
seed, it's just that now we keep the state in between calls and that will
feed into the next result, and that should make all the difference.
I made that hash be a per-cpu data just to avoid cache-line ping-pong:
having multiple CPU's write to the same data would be fine for randomness,
and add yet another layer of chaos to it, but since get_random_int() is
supposed to be a fast interface I did it that way instead. I considered
using "__raw_get_cpu_var()" to avoid any preemption overhead while still
getting the hash be _mostly_ ping-pong free, but in the end good taste won
out.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-05 23:17:43 +08:00
|
|
|
|
2017-01-22 23:34:08 +08:00
|
|
|
#if BITS_PER_LONG == 64
|
|
|
|
if (arch_get_random_long((unsigned long *)&ret))
|
2011-08-01 04:54:50 +08:00
|
|
|
return ret;
|
2017-01-22 23:34:08 +08:00
|
|
|
#else
|
|
|
|
if (arch_get_random_long((unsigned long *)&ret) &&
|
|
|
|
arch_get_random_long((unsigned long *)&ret + 1))
|
|
|
|
return ret;
|
|
|
|
#endif
|
2011-08-01 04:54:50 +08:00
|
|
|
|
2017-06-08 16:16:59 +08:00
|
|
|
warn_unseeded_randomness(&previous);
|
random: warn when kernel uses unseeded randomness
This enables an important dmesg notification about when drivers have
used the crng without it being seeded first. Prior, these errors would
occur silently, and so there hasn't been a great way of diagnosing these
types of bugs for obscure setups. By adding this as a config option, we
can leave it on by default, so that we learn where these issues happen,
in the field, will still allowing some people to turn it off, if they
really know what they're doing and do not want the log entries.
However, we don't leave it _completely_ by default. An earlier version
of this patch simply had `default y`. I'd really love that, but it turns
out, this problem with unseeded randomness being used is really quite
present and is going to take a long time to fix. Thus, as a compromise
between log-messages-for-all and nobody-knows, this is `default y`,
except it is also `depends on DEBUG_KERNEL`. This will ensure that the
curious see the messages while others don't have to.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-06-08 11:06:55 +08:00
|
|
|
|
2017-06-30 22:37:13 +08:00
|
|
|
use_lock = READ_ONCE(crng_init) < 2;
|
2017-01-22 23:34:08 +08:00
|
|
|
batch = &get_cpu_var(batched_entropy_u64);
|
random: invalidate batched entropy after crng init
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
2017-06-08 07:45:31 +08:00
|
|
|
if (use_lock)
|
|
|
|
read_lock_irqsave(&batched_entropy_reset_lock, flags);
|
2017-01-22 23:34:08 +08:00
|
|
|
if (batch->position % ARRAY_SIZE(batch->entropy_u64) == 0) {
|
2017-11-23 03:51:39 +08:00
|
|
|
extract_crng((__u32 *)batch->entropy_u64);
|
random: use chacha20 for get_random_int/long
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.
We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.
Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.
Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-01-07 02:32:01 +08:00
|
|
|
batch->position = 0;
|
|
|
|
}
|
2017-01-22 23:34:08 +08:00
|
|
|
ret = batch->entropy_u64[batch->position++];
|
random: invalidate batched entropy after crng init
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
2017-06-08 07:45:31 +08:00
|
|
|
if (use_lock)
|
|
|
|
read_unlock_irqrestore(&batched_entropy_reset_lock, flags);
|
2017-01-22 23:34:08 +08:00
|
|
|
put_cpu_var(batched_entropy_u64);
|
random: make get_random_int() more random
It's a really simple patch that basically just open-codes the current
"secure_ip_id()" call, but when open-coding it we now use a _static_
hashing area, so that it gets updated every time.
And to make sure somebody can't just start from the same original seed of
all-zeroes, and then do the "half_md4_transform()" over and over until
they get the same sequence as the kernel has, each iteration also mixes in
the same old "current->pid + jiffies" we used - so we should now have a
regular strong pseudo-number generator, but we also have one that doesn't
have a single seed.
Note: the "pid + jiffies" is just meant to be a tiny tiny bit of noise. It
has no real meaning. It could be anything. I just picked the previous
seed, it's just that now we keep the state in between calls and that will
feed into the next result, and that should make all the difference.
I made that hash be a per-cpu data just to avoid cache-line ping-pong:
having multiple CPU's write to the same data would be fine for randomness,
and add yet another layer of chaos to it, but since get_random_int() is
supposed to be a fast interface I did it that way instead. I considered
using "__raw_get_cpu_var()" to avoid any preemption overhead while still
getting the hash be _mostly_ ping-pong free, but in the end good taste won
out.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-05 23:17:43 +08:00
|
|
|
return ret;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2017-01-22 23:34:08 +08:00
|
|
|
EXPORT_SYMBOL(get_random_u64);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2017-01-22 23:34:08 +08:00
|
|
|
static DEFINE_PER_CPU(struct batched_entropy, batched_entropy_u32);
|
|
|
|
u32 get_random_u32(void)
|
random: use chacha20 for get_random_int/long
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.
We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.
Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.
Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-01-07 02:32:01 +08:00
|
|
|
{
|
2017-01-22 23:34:08 +08:00
|
|
|
u32 ret;
|
2017-06-30 22:37:13 +08:00
|
|
|
bool use_lock;
|
2017-06-15 06:45:26 +08:00
|
|
|
unsigned long flags = 0;
|
random: use chacha20 for get_random_int/long
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.
We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.
Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.
Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-01-07 02:32:01 +08:00
|
|
|
struct batched_entropy *batch;
|
2017-06-08 16:16:59 +08:00
|
|
|
static void *previous;
|
2016-02-27 07:19:34 +08:00
|
|
|
|
random: use chacha20 for get_random_int/long
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.
We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.
Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.
Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-01-07 02:32:01 +08:00
|
|
|
if (arch_get_random_int(&ret))
|
2016-02-27 07:19:34 +08:00
|
|
|
return ret;
|
|
|
|
|
2017-06-08 16:16:59 +08:00
|
|
|
warn_unseeded_randomness(&previous);
|
random: warn when kernel uses unseeded randomness
This enables an important dmesg notification about when drivers have
used the crng without it being seeded first. Prior, these errors would
occur silently, and so there hasn't been a great way of diagnosing these
types of bugs for obscure setups. By adding this as a config option, we
can leave it on by default, so that we learn where these issues happen,
in the field, will still allowing some people to turn it off, if they
really know what they're doing and do not want the log entries.
However, we don't leave it _completely_ by default. An earlier version
of this patch simply had `default y`. I'd really love that, but it turns
out, this problem with unseeded randomness being used is really quite
present and is going to take a long time to fix. Thus, as a compromise
between log-messages-for-all and nobody-knows, this is `default y`,
except it is also `depends on DEBUG_KERNEL`. This will ensure that the
curious see the messages while others don't have to.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-06-08 11:06:55 +08:00
|
|
|
|
2017-06-30 22:37:13 +08:00
|
|
|
use_lock = READ_ONCE(crng_init) < 2;
|
2017-01-22 23:34:08 +08:00
|
|
|
batch = &get_cpu_var(batched_entropy_u32);
|
random: invalidate batched entropy after crng init
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
2017-06-08 07:45:31 +08:00
|
|
|
if (use_lock)
|
|
|
|
read_lock_irqsave(&batched_entropy_reset_lock, flags);
|
2017-01-22 23:34:08 +08:00
|
|
|
if (batch->position % ARRAY_SIZE(batch->entropy_u32) == 0) {
|
2017-11-23 03:51:39 +08:00
|
|
|
extract_crng(batch->entropy_u32);
|
random: use chacha20 for get_random_int/long
Now that our crng uses chacha20, we can rely on its speedy
characteristics for replacing MD5, while simultaneously achieving a
higher security guarantee. Before the idea was to use these functions if
you wanted random integers that aren't stupidly insecure but aren't
necessarily secure either, a vague gray zone, that hopefully was "good
enough" for its users. With chacha20, we can strengthen this claim,
since either we're using an rdrand-like instruction, or we're using the
same crng as /dev/urandom. And it's faster than what was before.
We could have chosen to replace this with a SipHash-derived function,
which might be slightly faster, but at the cost of having yet another
RNG construction in the kernel. By moving to chacha20, we have a single
RNG to analyze and verify, and we also already get good performance
improvements on all platforms.
Implementation-wise, rather than use a generic buffer for both
get_random_int/long and memcpy based on the size needs, we use a
specific buffer for 32-bit reads and for 64-bit reads. This way, we're
guaranteed to always have aligned accesses on all platforms. While
slightly more verbose in C, the assembly this generates is a lot
simpler than otherwise.
Finally, on 32-bit platforms where longs and ints are the same size,
we simply alias get_random_int to get_random_long.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2017-01-07 02:32:01 +08:00
|
|
|
batch->position = 0;
|
|
|
|
}
|
2017-01-22 23:34:08 +08:00
|
|
|
ret = batch->entropy_u32[batch->position++];
|
random: invalidate batched entropy after crng init
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
2017-06-08 07:45:31 +08:00
|
|
|
if (use_lock)
|
|
|
|
read_unlock_irqrestore(&batched_entropy_reset_lock, flags);
|
2017-01-22 23:34:08 +08:00
|
|
|
put_cpu_var(batched_entropy_u32);
|
2016-02-27 07:19:34 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2017-01-22 23:34:08 +08:00
|
|
|
EXPORT_SYMBOL(get_random_u32);
|
2016-02-27 07:19:34 +08:00
|
|
|
|
random: invalidate batched entropy after crng init
It's possible that get_random_{u32,u64} is used before the crng has
initialized, in which case, its output might not be cryptographically
secure. For this problem, directly, this patch set is introducing the
*_wait variety of functions, but even with that, there's a subtle issue:
what happens to our batched entropy that was generated before
initialization. Prior to this commit, it'd stick around, supplying bad
numbers. After this commit, we force the entropy to be re-extracted
after each phase of the crng has initialized.
In order to avoid a race condition with the position counter, we
introduce a simple rwlock for this invalidation. Since it's only during
this awkward transition period, after things are all set up, we stop
using it, so that it doesn't have an impact on performance.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org # v4.11+
2017-06-08 07:45:31 +08:00
|
|
|
/* It's important to invalidate all potential batched entropy that might
|
|
|
|
* be stored before the crng is initialized, which we can do lazily by
|
|
|
|
* simply resetting the counter to zero so that it's re-extracted on the
|
|
|
|
* next usage. */
|
|
|
|
static void invalidate_batched_entropy(void)
|
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
write_lock_irqsave(&batched_entropy_reset_lock, flags);
|
|
|
|
for_each_possible_cpu (cpu) {
|
|
|
|
per_cpu_ptr(&batched_entropy_u32, cpu)->position = 0;
|
|
|
|
per_cpu_ptr(&batched_entropy_u64, cpu)->position = 0;
|
|
|
|
}
|
|
|
|
write_unlock_irqrestore(&batched_entropy_reset_lock, flags);
|
|
|
|
}
|
|
|
|
|
random: simplify API for random address requests
To date, all callers of randomize_range() have set the length to 0, and
check for a zero return value. For the current callers, the only way to
get zero returned is if end <= start. Since they are all adding a
constant to the start address, this is unnecessary.
We can remove a bunch of needless checks by simplifying the API to do just
what everyone wants, return an address between [start, start + range).
While we're here, s/get_random_int/get_random_long/. No current call site
is adversely affected by get_random_int(), since all current range
requests are < UINT_MAX. However, we should match caller expectations to
avoid coming up short (ha!) in the future.
All current callers to randomize_range() chose to use the start address if
randomize_range() failed. Therefore, we simplify things by just returning
the start address on error.
randomize_range() will be removed once all callers have been converted
over to randomize_addr().
Link: http://lkml.kernel.org/r/20160803233913.32511-2-jason@lakedaemon.net
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Roberts, William C" <william.c.roberts@intel.com>
Cc: Yann Droneaud <ydroneaud@opteya.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Nick Kralevich <nnk@google.com>
Cc: Jeffrey Vander Stoep <jeffv@google.com>
Cc: Daniel Cashman <dcashman@android.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-10-12 04:53:52 +08:00
|
|
|
/**
|
|
|
|
* randomize_page - Generate a random, page aligned address
|
|
|
|
* @start: The smallest acceptable address the caller will take.
|
|
|
|
* @range: The size of the area, starting at @start, within which the
|
|
|
|
* random address must fall.
|
|
|
|
*
|
|
|
|
* If @start + @range would overflow, @range is capped.
|
|
|
|
*
|
|
|
|
* NOTE: Historical use of randomize_range, which this replaces, presumed that
|
|
|
|
* @start was already page aligned. We now align it regardless.
|
|
|
|
*
|
|
|
|
* Return: A page aligned address within [start, start + range). On error,
|
|
|
|
* @start is returned.
|
|
|
|
*/
|
|
|
|
unsigned long
|
|
|
|
randomize_page(unsigned long start, unsigned long range)
|
|
|
|
{
|
|
|
|
if (!PAGE_ALIGNED(start)) {
|
|
|
|
range -= PAGE_ALIGN(start) - start;
|
|
|
|
start = PAGE_ALIGN(start);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (start > ULONG_MAX - range)
|
|
|
|
range = ULONG_MAX - start;
|
|
|
|
|
|
|
|
range >>= PAGE_SHIFT;
|
|
|
|
|
|
|
|
if (range == 0)
|
|
|
|
return start;
|
|
|
|
|
|
|
|
return start + (get_random_long() % range << PAGE_SHIFT);
|
|
|
|
}
|
|
|
|
|
2014-06-15 11:38:36 +08:00
|
|
|
/* Interface for in-kernel drivers of true hardware RNGs.
|
|
|
|
* Those devices may produce endless random bits and will be throttled
|
|
|
|
* when our pool is full.
|
|
|
|
*/
|
|
|
|
void add_hwgenerator_randomness(const char *buffer, size_t count,
|
|
|
|
size_t entropy)
|
|
|
|
{
|
|
|
|
struct entropy_store *poolp = &input_pool;
|
|
|
|
|
2018-04-12 01:27:52 +08:00
|
|
|
if (unlikely(crng_init == 0)) {
|
2016-06-13 06:13:36 +08:00
|
|
|
crng_fast_load(buffer, count);
|
|
|
|
return;
|
2016-06-13 06:11:51 +08:00
|
|
|
}
|
2016-06-13 06:13:36 +08:00
|
|
|
|
|
|
|
/* Suspend writing if we're above the trickle threshold.
|
|
|
|
* We'll be woken up again once below random_write_wakeup_thresh,
|
|
|
|
* or when the calling thread is about to terminate.
|
|
|
|
*/
|
|
|
|
wait_event_interruptible(random_write_wait, kthread_should_stop() ||
|
|
|
|
ENTROPY_BITS(&input_pool) <= random_write_wakeup_bits);
|
2014-06-15 11:38:36 +08:00
|
|
|
mix_pool_bytes(poolp, buffer, count);
|
|
|
|
credit_entropy_bits(poolp, entropy);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
|