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
|
|
|
|
* ===============================
|
|
|
|
*
|
2019-04-20 11:48:20 +08:00
|
|
|
* There are four exported interfaces; two for use within the kernel,
|
|
|
|
* and two or use from userspace.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2019-04-20 11:48:20 +08:00
|
|
|
* Exported interfaces ---- userspace output
|
|
|
|
* -----------------------------------------
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
2019-04-20 11:48:20 +08:00
|
|
|
* The userspace interfaces are two character devices /dev/random and
|
2005-04-17 06:20:36 +08:00
|
|
|
* /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.
|
|
|
|
*
|
2019-04-20 11:48:20 +08:00
|
|
|
* Exported interfaces ---- kernel output
|
|
|
|
* --------------------------------------
|
|
|
|
*
|
|
|
|
* The primary kernel interface is
|
|
|
|
*
|
|
|
|
* 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. This is equivalent to a
|
|
|
|
* read from /dev/urandom.
|
|
|
|
*
|
|
|
|
* For less critical applications, there are the functions:
|
|
|
|
*
|
|
|
|
* u32 get_random_u32()
|
|
|
|
* u64 get_random_u64()
|
|
|
|
* unsigned int get_random_int()
|
|
|
|
* unsigned long get_random_long()
|
|
|
|
*
|
|
|
|
* These are produced by a cryptographic RNG seeded from get_random_bytes,
|
|
|
|
* and so do not deplete the entropy pool as much. These are recommended
|
|
|
|
* for most in-kernel operations *if the result is going to be stored in
|
|
|
|
* the kernel*.
|
|
|
|
*
|
|
|
|
* Specifically, the get_random_int() family do not attempt to do
|
|
|
|
* "anti-backtracking". If you capture the state of the kernel (e.g.
|
|
|
|
* by snapshotting the VM), you can figure out previous get_random_int()
|
|
|
|
* return values. But if the value is stored in the kernel anyway,
|
|
|
|
* this is not a problem.
|
|
|
|
*
|
|
|
|
* It *is* safe to expose get_random_int() output to attackers (e.g. as
|
|
|
|
* network cookies); given outputs 1..n, it's not feasible to predict
|
|
|
|
* outputs 0 or n+1. The only concern is an attacker who breaks into
|
|
|
|
* the kernel later; the get_random_int() engine is not reseeded as
|
|
|
|
* often as the get_random_bytes() one.
|
|
|
|
*
|
|
|
|
* get_random_bytes() is needed for keys that need to stay secret after
|
|
|
|
* they are erased from the kernel. For example, any key that will
|
|
|
|
* be wrapped and stored encrypted. And session encryption keys: we'd
|
|
|
|
* like to know that after the session is closed and the keys erased,
|
|
|
|
* the plaintext is unrecoverable to someone who recorded the ciphertext.
|
|
|
|
*
|
|
|
|
* But for network ports/cookies, stack canaries, PRNG seeds, address
|
|
|
|
* space layout randomization, session *authentication* keys, or other
|
|
|
|
* applications where the sensitive data is stored in the kernel in
|
|
|
|
* plaintext for as long as it's sensitive, the get_random_int() family
|
|
|
|
* is just fine.
|
|
|
|
*
|
|
|
|
* Consider ASLR. We want to keep the address space secret from an
|
|
|
|
* outside attacker while the process is running, but once the address
|
|
|
|
* space is torn down, it's of no use to an attacker any more. And it's
|
|
|
|
* stored in kernel data structures as long as it's alive, so worrying
|
|
|
|
* about an attacker's ability to extrapolate it from the get_random_int()
|
|
|
|
* CRNG is silly.
|
|
|
|
*
|
|
|
|
* Even some cryptographic keys are safe to generate with get_random_int().
|
|
|
|
* In particular, keys for SipHash are generally fine. Here, knowledge
|
|
|
|
* of the key authorizes you to do something to a kernel object (inject
|
|
|
|
* packets to a network connection, or flood a hash table), and the
|
|
|
|
* key is stored with the object being protected. Once it goes away,
|
|
|
|
* we no longer care if anyone knows the key.
|
|
|
|
*
|
|
|
|
* prandom_u32()
|
|
|
|
* -------------
|
|
|
|
*
|
|
|
|
* For even weaker applications, see the pseudorandom generator
|
|
|
|
* prandom_u32(), prandom_max(), and prandom_bytes(). If the random
|
|
|
|
* numbers aren't security-critical at all, these are *far* cheaper.
|
|
|
|
* Useful for self-tests, random error simulation, randomized backoffs,
|
|
|
|
* and any other application where you trust that nobody is trying to
|
|
|
|
* maliciously mess with you by guessing the "random" numbers.
|
|
|
|
*
|
2005-04-17 06:20:36 +08:00
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2019-06-08 02:25:15 +08:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#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>
|
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>
|
2018-04-25 13:12:32 +08:00
|
|
|
#include <linux/ratelimit.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>
|
2018-11-17 09:26:21 +08:00
|
|
|
#include <crypto/chacha.h>
|
2020-05-03 02:24:27 +08:00
|
|
|
#include <crypto/sha.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 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
|
|
|
*
|
2018-11-02 19:04:46 +08:00
|
|
|
* 2*(ENTROPY_SHIFT + poolbitshift) must <= 31, or the multiply in
|
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
|
|
|
* 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
|
|
|
/*
|
|
|
|
* 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
|
|
|
*/
|
2018-11-02 19:04:45 +08:00
|
|
|
static const struct poolinfo {
|
2018-11-02 19:04:46 +08:00
|
|
|
int poolbitshift, poolwords, poolbytes, poolfracbits;
|
|
|
|
#define S(x) ilog2(x)+5, (x), (x)*4, (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 },
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Static global variables
|
|
|
|
*/
|
2018-06-29 00:43:44 +08:00
|
|
|
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;
|
|
|
|
};
|
|
|
|
|
2018-11-02 19:04:47 +08:00
|
|
|
static struct crng_state primary_crng = {
|
2016-06-13 06:13:36 +08:00
|
|
|
.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;
|
2018-11-17 09:26:21 +08:00
|
|
|
#define CRNG_INIT_CNT_THRESH (2*CHACHA_KEY_SIZE)
|
|
|
|
static void _extract_crng(struct crng_state *crng, __u8 out[CHACHA_BLOCK_SIZE]);
|
2016-05-05 01:29:18 +08:00
|
|
|
static void _crng_backtrack_protect(struct crng_state *crng,
|
2018-11-17 09:26:21 +08:00
|
|
|
__u8 tmp[CHACHA_BLOCK_SIZE], 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
|
|
|
|
2018-04-25 13:12:32 +08:00
|
|
|
static struct ratelimit_state unseeded_warning =
|
|
|
|
RATELIMIT_STATE_INIT("warn_unseeded_randomness", HZ, 3);
|
|
|
|
static struct ratelimit_state urandom_warning =
|
|
|
|
RATELIMIT_STATE_INIT("warn_urandom_randomness", HZ, 3);
|
|
|
|
|
|
|
|
static int ratelimit_disable __read_mostly;
|
|
|
|
|
|
|
|
module_param_named(ratelimit_disable, ratelimit_disable, int, 0644);
|
|
|
|
MODULE_PARM_DESC(ratelimit_disable, "Disable random ratelimit suppression");
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
/* read-write data: */
|
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
|
|
|
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);
|
2016-06-21 02:42:34 +08:00
|
|
|
static __u32 input_pool_data[INPUT_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
|
|
|
|
};
|
|
|
|
|
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
|
|
|
{
|
2019-02-21 05:06:38 +08:00
|
|
|
int entropy_count, orig, has_initialized = 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
|
|
|
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
|
|
|
|
2020-01-08 05:10:28 +08:00
|
|
|
if (WARN_ON(entropy_count < 0)) {
|
2019-06-08 02:25:15 +08:00
|
|
|
pr_warn("negative entropy/overflow: pool %s count %d\n",
|
2013-10-04 00:02:37 +08:00
|
|
|
r->name, entropy_count);
|
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
|
|
|
|
2019-05-23 00:02:16 +08:00
|
|
|
if (has_initialized) {
|
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
|
|
|
r->initialized = 1;
|
2019-05-23 00:02:16 +08:00
|
|
|
kill_fasync(&fasync, SIGIO, POLL_IN);
|
|
|
|
}
|
2012-07-02 19:52:16 +08:00
|
|
|
|
2013-09-11 11:16:17 +08:00
|
|
|
trace_credit_entropy_bits(r->name, nbits,
|
2019-02-21 05:06:38 +08:00
|
|
|
entropy_count >> ENTROPY_SHIFT, _RET_IP_);
|
2012-07-05 04:19:30 +08:00
|
|
|
|
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
|
|
|
|
2019-02-21 05:06:38 +08:00
|
|
|
if (crng_init < 2) {
|
|
|
|
if (entropy_bits < 128)
|
|
|
|
return;
|
2016-06-13 06:13:36 +08:00
|
|
|
crng_reseed(&primary_crng, r);
|
2019-06-08 02:25:14 +08:00
|
|
|
entropy_bits = ENTROPY_BITS(r);
|
2016-06-13 06:13:36 +08:00
|
|
|
}
|
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);
|
2019-04-20 11:35:16 +08:00
|
|
|
static void numa_crng_init(void);
|
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
|
|
|
|
2018-08-28 05:51:54 +08:00
|
|
|
static bool trust_cpu __ro_after_init = IS_ENABLED(CONFIG_RANDOM_TRUST_CPU);
|
|
|
|
static int __init parse_trust_cpu(char *arg)
|
|
|
|
{
|
|
|
|
return kstrtobool(arg, &trust_cpu);
|
|
|
|
}
|
|
|
|
early_param("random.trust_cpu", parse_trust_cpu);
|
|
|
|
|
2020-02-10 21:00:12 +08:00
|
|
|
static bool crng_init_try_arch(struct crng_state *crng)
|
2016-06-13 06:13:36 +08:00
|
|
|
{
|
|
|
|
int i;
|
2020-02-10 21:00:12 +08:00
|
|
|
bool arch_init = true;
|
2016-06-13 06:13:36 +08:00
|
|
|
unsigned long rv;
|
|
|
|
|
|
|
|
for (i = 4; i < 16; i++) {
|
|
|
|
if (!arch_get_random_seed_long(&rv) &&
|
2018-07-18 06:24:27 +08:00
|
|
|
!arch_get_random_long(&rv)) {
|
2016-06-13 06:13:36 +08:00
|
|
|
rv = random_get_entropy();
|
2020-02-10 21:00:12 +08:00
|
|
|
arch_init = false;
|
2018-07-18 06:24:27 +08:00
|
|
|
}
|
2016-06-13 06:13:36 +08:00
|
|
|
crng->state[i] ^= rv;
|
|
|
|
}
|
2020-02-10 21:00:12 +08:00
|
|
|
|
|
|
|
return arch_init;
|
|
|
|
}
|
|
|
|
|
2020-02-10 21:00:13 +08:00
|
|
|
static bool __init crng_init_try_arch_early(struct crng_state *crng)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
bool arch_init = true;
|
|
|
|
unsigned long rv;
|
|
|
|
|
|
|
|
for (i = 4; i < 16; i++) {
|
|
|
|
if (!arch_get_random_seed_long_early(&rv) &&
|
|
|
|
!arch_get_random_long_early(&rv)) {
|
|
|
|
rv = random_get_entropy();
|
|
|
|
arch_init = false;
|
|
|
|
}
|
|
|
|
crng->state[i] ^= rv;
|
|
|
|
}
|
|
|
|
|
|
|
|
return arch_init;
|
|
|
|
}
|
|
|
|
|
2020-03-10 20:09:12 +08:00
|
|
|
static void __maybe_unused crng_initialize_secondary(struct crng_state *crng)
|
2020-02-10 21:00:12 +08:00
|
|
|
{
|
|
|
|
memcpy(&crng->state[0], "expand 32-byte k", 16);
|
|
|
|
_get_random_bytes(&crng->state[4], sizeof(__u32) * 12);
|
|
|
|
crng_init_try_arch(crng);
|
|
|
|
crng->init_time = jiffies - CRNG_RESEED_INTERVAL - 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init crng_initialize_primary(struct crng_state *crng)
|
|
|
|
{
|
|
|
|
memcpy(&crng->state[0], "expand 32-byte k", 16);
|
|
|
|
_extract_entropy(&input_pool, &crng->state[4], sizeof(__u32) * 12, 0);
|
2020-02-10 21:00:13 +08:00
|
|
|
if (crng_init_try_arch_early(crng) && trust_cpu) {
|
2019-04-20 11:35:16 +08:00
|
|
|
invalidate_batched_entropy();
|
|
|
|
numa_crng_init();
|
2018-07-18 06:24:27 +08:00
|
|
|
crng_init = 2;
|
2019-06-08 02:25:15 +08:00
|
|
|
pr_notice("crng done (trusting CPU's manufacturer)\n");
|
2018-07-18 06:24:27 +08:00
|
|
|
}
|
2016-06-13 06:13:36 +08:00
|
|
|
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);
|
2020-02-10 21:00:12 +08:00
|
|
|
crng_initialize_secondary(crng);
|
2018-04-12 03:23:56 +08:00
|
|
|
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) {
|
2018-11-17 09:26:21 +08:00
|
|
|
p[crng_init_cnt % CHACHA_KEY_SIZE] ^= *cp;
|
2016-06-13 06:13:36 +08:00
|
|
|
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;
|
2019-06-08 02:25:15 +08:00
|
|
|
pr_notice("fast init done\n");
|
2016-06-13 06:13:36 +08:00
|
|
|
}
|
|
|
|
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;
|
2018-11-17 09:26:21 +08:00
|
|
|
unsigned i, max = CHACHA_KEY_SIZE;
|
2018-04-12 02:58:27 +08:00
|
|
|
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;
|
2018-11-17 09:26:21 +08:00
|
|
|
tmp = dest_buf[i % CHACHA_KEY_SIZE];
|
|
|
|
dest_buf[i % CHACHA_KEY_SIZE] ^= src_buf[i % len] ^ lfsr;
|
2018-04-12 02:58:27 +08:00
|
|
|
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 {
|
2018-11-17 09:26:21 +08:00
|
|
|
__u8 block[CHACHA_BLOCK_SIZE];
|
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,
|
2018-11-17 09:26:21 +08:00
|
|
|
CHACHA_KEY_SIZE);
|
2016-05-05 01:29:18 +08:00
|
|
|
}
|
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);
|
2019-12-23 16:20:48 +08:00
|
|
|
kill_fasync(&fasync, SIGIO, POLL_IN);
|
2019-06-08 02:25:15 +08:00
|
|
|
pr_notice("crng init done\n");
|
2018-04-25 13:12:32 +08:00
|
|
|
if (unseeded_warning.missed) {
|
2019-06-08 02:25:15 +08:00
|
|
|
pr_notice("%d get_random_xx warning(s) missed due to ratelimiting\n",
|
2018-04-25 13:12:32 +08:00
|
|
|
unseeded_warning.missed);
|
|
|
|
unseeded_warning.missed = 0;
|
|
|
|
}
|
|
|
|
if (urandom_warning.missed) {
|
2019-06-08 02:25:15 +08:00
|
|
|
pr_notice("%d urandom warning(s) missed due to ratelimiting\n",
|
2018-04-25 13:12:32 +08:00
|
|
|
urandom_warning.missed);
|
|
|
|
urandom_warning.missed = 0;
|
|
|
|
}
|
2016-06-13 06:13:36 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-02 14:04:41 +08:00
|
|
|
static void _extract_crng(struct crng_state *crng,
|
2018-11-17 09:26:21 +08:00
|
|
|
__u8 out[CHACHA_BLOCK_SIZE])
|
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);
|
|
|
|
}
|
|
|
|
|
2018-11-17 09:26:21 +08:00
|
|
|
static void extract_crng(__u8 out[CHACHA_BLOCK_SIZE])
|
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,
|
2018-11-17 09:26:21 +08:00
|
|
|
__u8 tmp[CHACHA_BLOCK_SIZE], int used)
|
2016-05-05 01:29:18 +08:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
__u32 *s, *d;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
used = round_up(used, sizeof(__u32));
|
2018-11-17 09:26:21 +08:00
|
|
|
if (used + CHACHA_KEY_SIZE > CHACHA_BLOCK_SIZE) {
|
2016-05-05 01:29:18 +08:00
|
|
|
extract_crng(tmp);
|
|
|
|
used = 0;
|
|
|
|
}
|
|
|
|
spin_lock_irqsave(&crng->lock, flags);
|
2018-09-12 11:05:10 +08:00
|
|
|
s = (__u32 *) &tmp[used];
|
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);
|
|
|
|
}
|
|
|
|
|
2018-11-17 09:26:21 +08:00
|
|
|
static void crng_backtrack_protect(__u8 tmp[CHACHA_BLOCK_SIZE], 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)
|
|
|
|
{
|
2018-11-17 09:26:21 +08:00
|
|
|
ssize_t ret = 0, i = CHACHA_BLOCK_SIZE;
|
|
|
|
__u8 tmp[CHACHA_BLOCK_SIZE] __aligned(4);
|
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);
|
2018-11-17 09:26:21 +08:00
|
|
|
i = min_t(int, nbytes, CHACHA_BLOCK_SIZE);
|
2016-06-13 06:13:36 +08:00
|
|
|
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;
|
|
|
|
|
|
|
|
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.
|
|
|
|
*/
|
2020-02-26 00:27:04 +08:00
|
|
|
delta = sample.jiffies - READ_ONCE(state->last_time);
|
|
|
|
WRITE_ONCE(state->last_time, sample.jiffies);
|
2018-03-01 07:22:47 +08:00
|
|
|
|
2020-02-26 00:27:04 +08:00
|
|
|
delta2 = delta - READ_ONCE(state->last_delta);
|
|
|
|
WRITE_ONCE(state->last_delta, delta);
|
2018-03-01 07:22:47 +08:00
|
|
|
|
2020-02-26 00:27:04 +08:00
|
|
|
delta3 = delta2 - READ_ONCE(state->last_delta2);
|
|
|
|
WRITE_ONCE(state->last_delta2, delta2);
|
2018-03-01 07:22:47 +08:00
|
|
|
|
|
|
|
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,
|
2020-01-08 05:55:34 +08:00
|
|
|
* and limit entropy estimate to 12 bits.
|
2018-03-01 07:22:47 +08:00
|
|
|
*/
|
|
|
|
credit_entropy_bits(r, min_t(int, fls(delta>>1), 11));
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
|
*
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
/*
|
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
|
|
|
|
2020-01-08 05:10:28 +08:00
|
|
|
if (WARN_ON(entropy_count < 0)) {
|
2019-06-08 02:25:15 +08:00
|
|
|
pr_warn("negative entropy count: pool %s count %d\n",
|
2014-07-19 05:26:41 +08:00
|
|
|
r->name, entropy_count);
|
|
|
|
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);
|
2019-06-08 02:25:14 +08:00
|
|
|
if (ibytes && ENTROPY_BITS(r) < random_write_wakeup_bits) {
|
2018-06-29 00:43:44 +08:00
|
|
|
wake_up_interruptible(&random_write_wait);
|
2013-03-05 00:59:12 +08:00
|
|
|
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;
|
2020-05-03 02:24:25 +08:00
|
|
|
__u32 workspace[SHA1_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
|
|
|
*/
|
2020-05-03 02:24:25 +08:00
|
|
|
sha1_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)
|
2020-05-03 02:24:25 +08:00
|
|
|
sha1_transform(hash.w, (__u8 *)(r->pool + i), workspace);
|
2013-12-18 10:16:39 +08:00
|
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
}
|
|
|
|
|
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
|
2018-04-25 13:12:32 +08:00
|
|
|
if (__ratelimit(&unseeded_warning))
|
char/random: silence a lockdep splat with printk()
Sergey didn't like the locking order,
uart_port->lock -> tty_port->lock
uart_write (uart_port->lock)
__uart_start
pl011_start_tx
pl011_tx_chars
uart_write_wakeup
tty_port_tty_wakeup
tty_port_default
tty_port_tty_get (tty_port->lock)
but those code is so old, and I have no clue how to de-couple it after
checking other locks in the splat. There is an onging effort to make all
printk() as deferred, so until that happens, workaround it for now as a
short-term fix.
LTP: starting iogen01 (export LTPROOT; rwtest -N iogen01 -i 120s -s
read,write -Da -Dv -n 2 500b:$TMPDIR/doio.f1.$$
1000b:$TMPDIR/doio.f2.$$)
WARNING: possible circular locking dependency detected
------------------------------------------------------
doio/49441 is trying to acquire lock:
ffff008b7cff7290 (&(&zone->lock)->rlock){..-.}, at: rmqueue+0x138/0x2050
but task is already holding lock:
60ff000822352818 (&pool->lock/1){-.-.}, at: start_flush_work+0xd8/0x3f0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #4 (&pool->lock/1){-.-.}:
lock_acquire+0x320/0x360
_raw_spin_lock+0x64/0x80
__queue_work+0x4b4/0xa10
queue_work_on+0xac/0x11c
tty_schedule_flip+0x84/0xbc
tty_flip_buffer_push+0x1c/0x28
pty_write+0x98/0xd0
n_tty_write+0x450/0x60c
tty_write+0x338/0x474
__vfs_write+0x88/0x214
vfs_write+0x12c/0x1a4
redirected_tty_write+0x90/0xdc
do_loop_readv_writev+0x140/0x180
do_iter_write+0xe0/0x10c
vfs_writev+0x134/0x1cc
do_writev+0xbc/0x130
__arm64_sys_writev+0x58/0x8c
el0_svc_handler+0x170/0x240
el0_sync_handler+0x150/0x250
el0_sync+0x164/0x180
-> #3 (&(&port->lock)->rlock){-.-.}:
lock_acquire+0x320/0x360
_raw_spin_lock_irqsave+0x7c/0x9c
tty_port_tty_get+0x24/0x60
tty_port_default_wakeup+0x1c/0x3c
tty_port_tty_wakeup+0x34/0x40
uart_write_wakeup+0x28/0x44
pl011_tx_chars+0x1b8/0x270
pl011_start_tx+0x24/0x70
__uart_start+0x5c/0x68
uart_write+0x164/0x1c8
do_output_char+0x33c/0x348
n_tty_write+0x4bc/0x60c
tty_write+0x338/0x474
redirected_tty_write+0xc0/0xdc
do_loop_readv_writev+0x140/0x180
do_iter_write+0xe0/0x10c
vfs_writev+0x134/0x1cc
do_writev+0xbc/0x130
__arm64_sys_writev+0x58/0x8c
el0_svc_handler+0x170/0x240
el0_sync_handler+0x150/0x250
el0_sync+0x164/0x180
-> #2 (&port_lock_key){-.-.}:
lock_acquire+0x320/0x360
_raw_spin_lock+0x64/0x80
pl011_console_write+0xec/0x2cc
console_unlock+0x794/0x96c
vprintk_emit+0x260/0x31c
vprintk_default+0x54/0x7c
vprintk_func+0x218/0x254
printk+0x7c/0xa4
register_console+0x734/0x7b0
uart_add_one_port+0x734/0x834
pl011_register_port+0x6c/0xac
sbsa_uart_probe+0x234/0x2ec
platform_drv_probe+0xd4/0x124
really_probe+0x250/0x71c
driver_probe_device+0xb4/0x200
__device_attach_driver+0xd8/0x188
bus_for_each_drv+0xbc/0x110
__device_attach+0x120/0x220
device_initial_probe+0x20/0x2c
bus_probe_device+0x54/0x100
device_add+0xae8/0xc2c
platform_device_add+0x278/0x3b8
platform_device_register_full+0x238/0x2ac
acpi_create_platform_device+0x2dc/0x3a8
acpi_bus_attach+0x390/0x3cc
acpi_bus_attach+0x108/0x3cc
acpi_bus_attach+0x108/0x3cc
acpi_bus_attach+0x108/0x3cc
acpi_bus_scan+0x7c/0xb0
acpi_scan_init+0xe4/0x304
acpi_init+0x100/0x114
do_one_initcall+0x348/0x6a0
do_initcall_level+0x190/0x1fc
do_basic_setup+0x34/0x4c
kernel_init_freeable+0x19c/0x260
kernel_init+0x18/0x338
ret_from_fork+0x10/0x18
-> #1 (console_owner){-...}:
lock_acquire+0x320/0x360
console_lock_spinning_enable+0x6c/0x7c
console_unlock+0x4f8/0x96c
vprintk_emit+0x260/0x31c
vprintk_default+0x54/0x7c
vprintk_func+0x218/0x254
printk+0x7c/0xa4
get_random_u64+0x1c4/0x1dc
shuffle_pick_tail+0x40/0xac
__free_one_page+0x424/0x710
free_one_page+0x70/0x120
__free_pages_ok+0x61c/0xa94
__free_pages_core+0x1bc/0x294
memblock_free_pages+0x38/0x48
__free_pages_memory+0xcc/0xfc
__free_memory_core+0x70/0x78
free_low_memory_core_early+0x148/0x18c
memblock_free_all+0x18/0x54
mem_init+0xb4/0x17c
mm_init+0x14/0x38
start_kernel+0x19c/0x530
-> #0 (&(&zone->lock)->rlock){..-.}:
validate_chain+0xf6c/0x2e2c
__lock_acquire+0x868/0xc2c
lock_acquire+0x320/0x360
_raw_spin_lock+0x64/0x80
rmqueue+0x138/0x2050
get_page_from_freelist+0x474/0x688
__alloc_pages_nodemask+0x3b4/0x18dc
alloc_pages_current+0xd0/0xe0
alloc_slab_page+0x2b4/0x5e0
new_slab+0xc8/0x6bc
___slab_alloc+0x3b8/0x640
kmem_cache_alloc+0x4b4/0x588
__debug_object_init+0x778/0x8b4
debug_object_init_on_stack+0x40/0x50
start_flush_work+0x16c/0x3f0
__flush_work+0xb8/0x124
flush_work+0x20/0x30
xlog_cil_force_lsn+0x88/0x204 [xfs]
xfs_log_force_lsn+0x128/0x1b8 [xfs]
xfs_file_fsync+0x3c4/0x488 [xfs]
vfs_fsync_range+0xb0/0xd0
generic_write_sync+0x80/0xa0 [xfs]
xfs_file_buffered_aio_write+0x66c/0x6e4 [xfs]
xfs_file_write_iter+0x1a0/0x218 [xfs]
__vfs_write+0x1cc/0x214
vfs_write+0x12c/0x1a4
ksys_write+0xb0/0x120
__arm64_sys_write+0x54/0x88
el0_svc_handler+0x170/0x240
el0_sync_handler+0x150/0x250
el0_sync+0x164/0x180
other info that might help us debug this:
Chain exists of:
&(&zone->lock)->rlock --> &(&port->lock)->rlock --> &pool->lock/1
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&pool->lock/1);
lock(&(&port->lock)->rlock);
lock(&pool->lock/1);
lock(&(&zone->lock)->rlock);
*** DEADLOCK ***
4 locks held by doio/49441:
#0: a0ff00886fc27408 (sb_writers#8){.+.+}, at: vfs_write+0x118/0x1a4
#1: 8fff00080810dfe0 (&xfs_nondir_ilock_class){++++}, at:
xfs_ilock+0x2a8/0x300 [xfs]
#2: ffff9000129f2390 (rcu_read_lock){....}, at:
rcu_lock_acquire+0x8/0x38
#3: 60ff000822352818 (&pool->lock/1){-.-.}, at:
start_flush_work+0xd8/0x3f0
stack backtrace:
CPU: 48 PID: 49441 Comm: doio Tainted: G W
Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS
L50_5.13_1.11 06/18/2019
Call trace:
dump_backtrace+0x0/0x248
show_stack+0x20/0x2c
dump_stack+0xe8/0x150
print_circular_bug+0x368/0x380
check_noncircular+0x28c/0x294
validate_chain+0xf6c/0x2e2c
__lock_acquire+0x868/0xc2c
lock_acquire+0x320/0x360
_raw_spin_lock+0x64/0x80
rmqueue+0x138/0x2050
get_page_from_freelist+0x474/0x688
__alloc_pages_nodemask+0x3b4/0x18dc
alloc_pages_current+0xd0/0xe0
alloc_slab_page+0x2b4/0x5e0
new_slab+0xc8/0x6bc
___slab_alloc+0x3b8/0x640
kmem_cache_alloc+0x4b4/0x588
__debug_object_init+0x778/0x8b4
debug_object_init_on_stack+0x40/0x50
start_flush_work+0x16c/0x3f0
__flush_work+0xb8/0x124
flush_work+0x20/0x30
xlog_cil_force_lsn+0x88/0x204 [xfs]
xfs_log_force_lsn+0x128/0x1b8 [xfs]
xfs_file_fsync+0x3c4/0x488 [xfs]
vfs_fsync_range+0xb0/0xd0
generic_write_sync+0x80/0xa0 [xfs]
xfs_file_buffered_aio_write+0x66c/0x6e4 [xfs]
xfs_file_write_iter+0x1a0/0x218 [xfs]
__vfs_write+0x1cc/0x214
vfs_write+0x12c/0x1a4
ksys_write+0xb0/0x120
__arm64_sys_write+0x54/0x88
el0_svc_handler+0x170/0x240
el0_sync_handler+0x150/0x250
el0_sync+0x164/0x180
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Signed-off-by: Qian Cai <cai@lca.pw>
Link: https://lore.kernel.org/r/1573679785-21068-1-git-send-email-cai@lca.pw
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2019-11-14 05:16:25 +08:00
|
|
|
printk_deferred(KERN_NOTICE "random: %s called from %pS "
|
|
|
|
"with crng_init=%d\n", func_name, caller,
|
|
|
|
crng_init);
|
2017-06-08 16:16:59 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
2018-11-17 09:26:21 +08:00
|
|
|
__u8 tmp[CHACHA_BLOCK_SIZE] __aligned(4);
|
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
|
|
|
|
2018-11-17 09:26:21 +08:00
|
|
|
while (nbytes >= CHACHA_BLOCK_SIZE) {
|
2016-06-13 06:13:36 +08:00
|
|
|
extract_crng(buf);
|
2018-11-17 09:26:21 +08:00
|
|
|
buf += CHACHA_BLOCK_SIZE;
|
|
|
|
nbytes -= CHACHA_BLOCK_SIZE;
|
2016-06-13 06:13:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (nbytes > 0) {
|
|
|
|
extract_crng(tmp);
|
|
|
|
memcpy(buf, tmp, nbytes);
|
2016-05-05 01:29:18 +08:00
|
|
|
crng_backtrack_protect(tmp, nbytes);
|
|
|
|
} else
|
2018-11-17 09:26:21 +08:00
|
|
|
crng_backtrack_protect(tmp, CHACHA_BLOCK_SIZE);
|
2016-05-05 01:29:18 +08:00
|
|
|
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);
|
|
|
|
|
random: try to actively add entropy rather than passively wait for it
For 5.3 we had to revert a nice ext4 IO pattern improvement, because it
caused a bootup regression due to lack of entropy at bootup together
with arguably broken user space that was asking for secure random
numbers when it really didn't need to.
See commit 72dbcf721566 (Revert "ext4: make __ext4_get_inode_loc plug").
This aims to solve the issue by actively generating entropy noise using
the CPU cycle counter when waiting for the random number generator to
initialize. This only works when you have a high-frequency time stamp
counter available, but that's the case on all modern x86 CPU's, and on
most other modern CPU's too.
What we do is to generate jitter entropy from the CPU cycle counter
under a somewhat complex load: calling the scheduler while also
guaranteeing a certain amount of timing noise by also triggering a
timer.
I'm sure we can tweak this, and that people will want to look at other
alternatives, but there's been a number of papers written on jitter
entropy, and this should really be fairly conservative by crediting one
bit of entropy for every timer-induced jump in the cycle counter. Not
because the timer itself would be all that unpredictable, but because
the interaction between the timer and the loop is going to be.
Even if (and perhaps particularly if) the timer actually happens on
another CPU, the cacheline interaction between the loop that reads the
cycle counter and the timer itself firing is going to add perturbations
to the cycle counter values that get mixed into the entropy pool.
As Thomas pointed out, with a modern out-of-order CPU, even quite simple
loops show a fair amount of hard-to-predict timing variability even in
the absense of external interrupts. But this tries to take that further
by actually having a fairly complex interaction.
This is not going to solve the entropy issue for architectures that have
no CPU cycle counter, but it's not clear how (and if) that is solvable,
and the hardware in question is largely starting to be irrelevant. And
by doing this we can at least avoid some of the even more contentious
approaches (like making the entropy waiting time out in order to avoid
the possibly unbounded waiting).
Cc: Ahmed Darwish <darwish.07@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Nicholas Mc Guire <hofrat@opentech.at>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Alexander E. Patrakov <patrakov@gmail.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-09-29 07:53:52 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Each time the timer fires, we expect that we got an unpredictable
|
|
|
|
* jump in the cycle counter. Even if the timer is running on another
|
|
|
|
* CPU, the timer activity will be touching the stack of the CPU that is
|
|
|
|
* generating entropy..
|
|
|
|
*
|
|
|
|
* Note that we don't re-arm the timer in the timer itself - we are
|
|
|
|
* happy to be scheduled away, since that just makes the load more
|
|
|
|
* complex, but we do not want the timer to keep ticking unless the
|
|
|
|
* entropy loop is running.
|
|
|
|
*
|
|
|
|
* So the re-arming always happens in the entropy loop itself.
|
|
|
|
*/
|
|
|
|
static void entropy_timer(struct timer_list *t)
|
|
|
|
{
|
|
|
|
credit_entropy_bits(&input_pool, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have an actual cycle counter, see if we can
|
|
|
|
* generate enough entropy with timing noise
|
|
|
|
*/
|
|
|
|
static void try_to_generate_entropy(void)
|
|
|
|
{
|
|
|
|
struct {
|
|
|
|
unsigned long now;
|
|
|
|
struct timer_list timer;
|
|
|
|
} stack;
|
|
|
|
|
|
|
|
stack.now = random_get_entropy();
|
|
|
|
|
|
|
|
/* Slow counter - or none. Don't even bother */
|
|
|
|
if (stack.now == random_get_entropy())
|
|
|
|
return;
|
|
|
|
|
|
|
|
timer_setup_on_stack(&stack.timer, entropy_timer, 0);
|
|
|
|
while (!crng_ready()) {
|
|
|
|
if (!timer_pending(&stack.timer))
|
|
|
|
mod_timer(&stack.timer, jiffies+1);
|
|
|
|
mix_pool_bytes(&input_pool, &stack.now, sizeof(stack.now));
|
|
|
|
schedule();
|
|
|
|
stack.now = random_get_entropy();
|
|
|
|
}
|
|
|
|
|
|
|
|
del_timer_sync(&stack.timer);
|
|
|
|
destroy_timer_on_stack(&stack.timer);
|
|
|
|
mix_pool_bytes(&input_pool, &stack.now, sizeof(stack.now));
|
|
|
|
}
|
|
|
|
|
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;
|
random: try to actively add entropy rather than passively wait for it
For 5.3 we had to revert a nice ext4 IO pattern improvement, because it
caused a bootup regression due to lack of entropy at bootup together
with arguably broken user space that was asking for secure random
numbers when it really didn't need to.
See commit 72dbcf721566 (Revert "ext4: make __ext4_get_inode_loc plug").
This aims to solve the issue by actively generating entropy noise using
the CPU cycle counter when waiting for the random number generator to
initialize. This only works when you have a high-frequency time stamp
counter available, but that's the case on all modern x86 CPU's, and on
most other modern CPU's too.
What we do is to generate jitter entropy from the CPU cycle counter
under a somewhat complex load: calling the scheduler while also
guaranteeing a certain amount of timing noise by also triggering a
timer.
I'm sure we can tweak this, and that people will want to look at other
alternatives, but there's been a number of papers written on jitter
entropy, and this should really be fairly conservative by crediting one
bit of entropy for every timer-induced jump in the cycle counter. Not
because the timer itself would be all that unpredictable, but because
the interaction between the timer and the loop is going to be.
Even if (and perhaps particularly if) the timer actually happens on
another CPU, the cacheline interaction between the loop that reads the
cycle counter and the timer itself firing is going to add perturbations
to the cycle counter values that get mixed into the entropy pool.
As Thomas pointed out, with a modern out-of-order CPU, even quite simple
loops show a fair amount of hard-to-predict timing variability even in
the absense of external interrupts. But this tries to take that further
by actually having a fairly complex interaction.
This is not going to solve the entropy issue for architectures that have
no CPU cycle counter, but it's not clear how (and if) that is solvable,
and the hardware in question is largely starting to be irrelevant. And
by doing this we can at least avoid some of the even more contentious
approaches (like making the entropy waiting time out in order to avoid
the possibly unbounded waiting).
Cc: Ahmed Darwish <darwish.07@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Nicholas Mc Guire <hofrat@opentech.at>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Alexander E. Patrakov <patrakov@gmail.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-09-29 07:53:52 +08:00
|
|
|
|
|
|
|
do {
|
|
|
|
int ret;
|
|
|
|
ret = wait_event_interruptible_timeout(crng_init_wait, crng_ready(), HZ);
|
|
|
|
if (ret)
|
|
|
|
return ret > 0 ? 0 : ret;
|
|
|
|
|
|
|
|
try_to_generate_entropy();
|
|
|
|
} while (!crng_ready());
|
|
|
|
|
|
|
|
return 0;
|
2017-06-08 07:58:56 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(wait_for_random_bytes);
|
|
|
|
|
2018-08-01 03:11:00 +08:00
|
|
|
/*
|
|
|
|
* Returns whether or not the urandom pool has been 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.
|
|
|
|
*
|
|
|
|
* Returns: true if the urandom pool has been seeded.
|
|
|
|
* false if the urandom pool has not been seeded.
|
|
|
|
*/
|
|
|
|
bool rng_is_initialized(void)
|
|
|
|
{
|
|
|
|
return crng_ready();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(rng_is_initialized);
|
|
|
|
|
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.
|
2018-06-22 07:15:32 +08:00
|
|
|
*
|
|
|
|
* Return number of bytes filled in.
|
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
|
|
|
*/
|
2018-06-22 07:15:32 +08:00
|
|
|
int __must_check get_random_bytes_arch(void *buf, int nbytes)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2018-06-22 07:15:32 +08:00
|
|
|
int left = nbytes;
|
2011-08-01 04:54:50 +08:00
|
|
|
char *p = buf;
|
|
|
|
|
2018-06-22 07:15:32 +08:00
|
|
|
trace_get_random_bytes_arch(left, _RET_IP_);
|
|
|
|
while (left) {
|
2011-08-01 04:54:50 +08:00
|
|
|
unsigned long v;
|
2018-06-22 07:15:32 +08:00
|
|
|
int chunk = min_t(int, left, 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;
|
2018-06-22 07:15:31 +08:00
|
|
|
|
2011-11-17 02:50:56 +08:00
|
|
|
memcpy(p, &v, chunk);
|
2011-08-01 04:54:50 +08:00
|
|
|
p += chunk;
|
2018-06-22 07:15:32 +08:00
|
|
|
left -= chunk;
|
2011-08-01 04:54:50 +08:00
|
|
|
}
|
|
|
|
|
2018-06-22 07:15:32 +08:00
|
|
|
return nbytes - left;
|
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.
|
|
|
|
*/
|
2019-04-20 11:27:05 +08:00
|
|
|
static void __init init_std_data(struct entropy_store *r)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
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
|
|
|
|
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.
|
|
|
|
*/
|
2019-04-20 11:27:05 +08:00
|
|
|
int __init rand_initialize(void)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
init_std_data(&input_pool);
|
2020-02-10 21:00:12 +08:00
|
|
|
crng_initialize_primary(&primary_crng);
|
2018-04-12 04:32:17 +08:00
|
|
|
crng_global_init_time = jiffies;
|
2018-04-25 13:12:32 +08:00
|
|
|
if (ratelimit_disable) {
|
|
|
|
urandom_warning.interval = 0;
|
|
|
|
unseeded_warning.interval = 0;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
[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
|
|
|
|
2019-12-23 16:20:45 +08:00
|
|
|
static ssize_t
|
|
|
|
urandom_read_nowarn(struct file *file, char __user *buf, size_t nbytes,
|
|
|
|
loff_t *ppos)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
|
|
|
|
ret = extract_crng_user(buf, nbytes);
|
|
|
|
trace_urandom_read(8 * nbytes, 0, ENTROPY_BITS(&input_pool));
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2016-06-13 06:13:36 +08:00
|
|
|
if (!crng_ready() && maxwarn > 0) {
|
2016-06-13 22:10:51 +08:00
|
|
|
maxwarn--;
|
2018-04-25 13:12:32 +08:00
|
|
|
if (__ratelimit(&urandom_warning))
|
2019-06-08 02:25:15 +08:00
|
|
|
pr_notice("%s: uninitialized urandom read (%zd bytes read)\n",
|
|
|
|
current->comm, nbytes);
|
2016-06-13 06:13:36 +08:00
|
|
|
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
|
|
|
}
|
2019-12-23 16:20:45 +08:00
|
|
|
|
|
|
|
return urandom_read_nowarn(file, buf, nbytes, ppos);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2019-12-23 16:20:48 +08:00
|
|
|
static ssize_t
|
|
|
|
random_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = wait_for_random_bytes();
|
|
|
|
if (ret != 0)
|
|
|
|
return ret;
|
|
|
|
return urandom_read_nowarn(file, buf, nbytes, ppos);
|
|
|
|
}
|
|
|
|
|
2017-07-03 18:39:46 +08:00
|
|
|
static __poll_t
|
2018-06-29 00:43:44 +08:00
|
|
|
random_poll(struct file *file, poll_table * wait)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2018-06-29 00:43:44 +08:00
|
|
|
__poll_t mask;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2019-12-23 16:20:48 +08:00
|
|
|
poll_wait(file, &crng_init_wait, wait);
|
2018-06-29 00:43:44 +08:00
|
|
|
poll_wait(file, &random_write_wait, wait);
|
|
|
|
mask = 0;
|
2019-12-23 16:20:48 +08:00
|
|
|
if (crng_ready())
|
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;
|
random: mix rdrand with entropy sent in from userspace
Fedora has integrated the jitter entropy daemon to work around slow
boot problems, especially on VM's that don't support virtio-rng:
https://bugzilla.redhat.com/show_bug.cgi?id=1572944
It's understandable why they did this, but the Jitter entropy daemon
works fundamentally on the principle: "the CPU microarchitecture is
**so** complicated and we can't figure it out, so it *must* be
random". Yes, it uses statistical tests to "prove" it is secure, but
AES_ENCRYPT(NSA_KEY, COUNTER++) will also pass statistical tests with
flying colors.
So if RDRAND is available, mix it into entropy submitted from
userspace. It can't hurt, and if you believe the NSA has backdoored
RDRAND, then they probably have enough details about the Intel
microarchitecture that they can reverse engineer how the Jitter
entropy daemon affects the microarchitecture, and attack its output
stream. And if RDRAND is in fact an honest DRNG, it will immeasurably
improve on what the Jitter entropy daemon might produce.
This also provides some protection against someone who is able to read
or set the entropy seed file.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>
2018-07-15 11:55:57 +08:00
|
|
|
__u32 t, buf[16];
|
2005-04-17 06:20:36 +08:00
|
|
|
const char __user *p = buffer;
|
|
|
|
|
2007-05-30 10:58:10 +08:00
|
|
|
while (count > 0) {
|
random: mix rdrand with entropy sent in from userspace
Fedora has integrated the jitter entropy daemon to work around slow
boot problems, especially on VM's that don't support virtio-rng:
https://bugzilla.redhat.com/show_bug.cgi?id=1572944
It's understandable why they did this, but the Jitter entropy daemon
works fundamentally on the principle: "the CPU microarchitecture is
**so** complicated and we can't figure it out, so it *must* be
random". Yes, it uses statistical tests to "prove" it is secure, but
AES_ENCRYPT(NSA_KEY, COUNTER++) will also pass statistical tests with
flying colors.
So if RDRAND is available, mix it into entropy submitted from
userspace. It can't hurt, and if you believe the NSA has backdoored
RDRAND, then they probably have enough details about the Intel
microarchitecture that they can reverse engineer how the Jitter
entropy daemon affects the microarchitecture, and attack its output
stream. And if RDRAND is in fact an honest DRNG, it will immeasurably
improve on what the Jitter entropy daemon might produce.
This also provides some protection against someone who is able to read
or set the entropy seed file.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>
2018-07-15 11:55:57 +08:00
|
|
|
int b, i = 0;
|
|
|
|
|
2007-05-30 10:58:10 +08:00
|
|
|
bytes = min(count, sizeof(buf));
|
|
|
|
if (copy_from_user(&buf, p, bytes))
|
|
|
|
return -EFAULT;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
random: mix rdrand with entropy sent in from userspace
Fedora has integrated the jitter entropy daemon to work around slow
boot problems, especially on VM's that don't support virtio-rng:
https://bugzilla.redhat.com/show_bug.cgi?id=1572944
It's understandable why they did this, but the Jitter entropy daemon
works fundamentally on the principle: "the CPU microarchitecture is
**so** complicated and we can't figure it out, so it *must* be
random". Yes, it uses statistical tests to "prove" it is secure, but
AES_ENCRYPT(NSA_KEY, COUNTER++) will also pass statistical tests with
flying colors.
So if RDRAND is available, mix it into entropy submitted from
userspace. It can't hurt, and if you believe the NSA has backdoored
RDRAND, then they probably have enough details about the Intel
microarchitecture that they can reverse engineer how the Jitter
entropy daemon affects the microarchitecture, and attack its output
stream. And if RDRAND is in fact an honest DRNG, it will immeasurably
improve on what the Jitter entropy daemon might produce.
This also provides some protection against someone who is able to read
or set the entropy seed file.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>
2018-07-15 11:55:57 +08:00
|
|
|
for (b = bytes ; b > 0 ; b -= sizeof(__u32), i++) {
|
|
|
|
if (!arch_get_random_int(&t))
|
|
|
|
break;
|
|
|
|
buf[i] ^= t;
|
|
|
|
}
|
|
|
|
|
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;
|
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,
|
2018-06-29 00:43:44 +08:00
|
|
|
.poll = random_poll,
|
2008-04-29 16:02:58 +08:00
|
|
|
.unlocked_ioctl = random_ioctl,
|
2018-09-07 17:10:23 +08:00
|
|
|
.compat_ioctl = compat_ptr_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,
|
2019-12-18 01:24:55 +08:00
|
|
|
.compat_ioctl = compat_ptr_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;
|
|
|
|
|
2019-12-23 16:20:46 +08:00
|
|
|
if (flags & ~(GRND_NONBLOCK|GRND_RANDOM|GRND_INSECURE))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Requesting insecure and blocking randomness at the same time makes
|
|
|
|
* no sense.
|
|
|
|
*/
|
|
|
|
if ((flags & (GRND_INSECURE|GRND_RANDOM)) == (GRND_INSECURE|GRND_RANDOM))
|
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 -EINVAL;
|
|
|
|
|
|
|
|
if (count > INT_MAX)
|
|
|
|
count = INT_MAX;
|
|
|
|
|
2019-12-23 16:20:46 +08:00
|
|
|
if (!(flags & GRND_INSECURE) && !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
|
|
|
}
|
2019-12-23 16:20:45 +08:00
|
|
|
return urandom_read_nowarn(NULL, buf, count, NULL);
|
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
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/********************************************************************
|
|
|
|
*
|
|
|
|
* Sysctl interface
|
|
|
|
*
|
|
|
|
********************************************************************/
|
|
|
|
|
|
|
|
#ifdef CONFIG_SYSCTL
|
|
|
|
|
|
|
|
#include <linux/sysctl.h>
|
|
|
|
|
2019-12-23 16:20:51 +08:00
|
|
|
static int min_write_thresh;
|
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,
|
2020-04-24 14:43:38 +08:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
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,
|
2020-06-03 13:52:36 +08:00
|
|
|
void *buffer, size_t *lenp, loff_t *ppos)
|
2013-09-11 11:16:17 +08:00
|
|
|
{
|
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 = "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 {
|
2018-11-17 09:26:21 +08:00
|
|
|
u64 entropy_u64[CHACHA_BLOCK_SIZE / sizeof(u64)];
|
|
|
|
u32 entropy_u32[CHACHA_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;
|
2019-04-20 12:09:51 +08:00
|
|
|
spinlock_t batch_lock;
|
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
|
|
|
};
|
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
|
random: always use batched entropy for get_random_u{32,64}
It turns out that RDRAND is pretty slow. Comparing these two
constructions:
for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret))
arch_get_random_long(&ret);
and
long buf[CHACHA_BLOCK_SIZE / sizeof(long)];
extract_crng((u8 *)buf);
it amortizes out to 352 cycles per long for the top one and 107 cycles
per long for the bottom one, on Coffee Lake Refresh, Intel Core i9-9880H.
And importantly, the top one has the drawback of not benefiting from the
real rng, whereas the bottom one has all the nice benefits of using our
own chacha rng. As get_random_u{32,64} gets used in more places (perhaps
beyond what it was originally intended for when it was introduced as
get_random_{int,long} back in the md5 monstrosity era), it seems like it
might be a good thing to strengthen its posture a tiny bit. Doing this
should only be stronger and not any weaker because that pool is already
initialized with a bunch of rdrand data (when available). This way, we
get the benefits of the hardware rng as well as our own rng.
Another benefit of this is that we no longer hit pitfalls of the recent
stream of AMD bugs in RDRAND. One often used code pattern for various
things is:
do {
val = get_random_u32();
} while (hash_table_contains_key(val));
That recent AMD bug rendered that pattern useless, whereas we're really
very certain that chacha20 output will give pretty distributed numbers,
no matter what.
So, this simplification seems better both from a security perspective
and from a performance perspective.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200221201037.30231-1-Jason@zx2c4.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-02-22 04:10:37 +08:00
|
|
|
* number is good as /dev/urandom, but there is no backtrack protection, with
|
|
|
|
* the goal of being quite fast and not depleting entropy. In order to ensure
|
2017-06-08 07:58:56 +08:00
|
|
|
* that the randomness provided by this function is okay, the function
|
random: always use batched entropy for get_random_u{32,64}
It turns out that RDRAND is pretty slow. Comparing these two
constructions:
for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret))
arch_get_random_long(&ret);
and
long buf[CHACHA_BLOCK_SIZE / sizeof(long)];
extract_crng((u8 *)buf);
it amortizes out to 352 cycles per long for the top one and 107 cycles
per long for the bottom one, on Coffee Lake Refresh, Intel Core i9-9880H.
And importantly, the top one has the drawback of not benefiting from the
real rng, whereas the bottom one has all the nice benefits of using our
own chacha rng. As get_random_u{32,64} gets used in more places (perhaps
beyond what it was originally intended for when it was introduced as
get_random_{int,long} back in the md5 monstrosity era), it seems like it
might be a good thing to strengthen its posture a tiny bit. Doing this
should only be stronger and not any weaker because that pool is already
initialized with a bunch of rdrand data (when available). This way, we
get the benefits of the hardware rng as well as our own rng.
Another benefit of this is that we no longer hit pitfalls of the recent
stream of AMD bugs in RDRAND. One often used code pattern for various
things is:
do {
val = get_random_u32();
} while (hash_table_contains_key(val));
That recent AMD bug rendered that pattern useless, whereas we're really
very certain that chacha20 output will give pretty distributed numbers,
no matter what.
So, this simplification seems better both from a security perspective
and from a performance perspective.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200221201037.30231-1-Jason@zx2c4.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-02-22 04:10:37 +08:00
|
|
|
* 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
|
|
|
*/
|
2019-04-20 12:09:51 +08:00
|
|
|
static DEFINE_PER_CPU(struct batched_entropy, batched_entropy_u64) = {
|
|
|
|
.batch_lock = __SPIN_LOCK_UNLOCKED(batched_entropy_u64.lock),
|
|
|
|
};
|
|
|
|
|
2017-01-22 23:34:08 +08:00
|
|
|
u64 get_random_u64(void)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2017-01-22 23:34:08 +08:00
|
|
|
u64 ret;
|
2019-04-20 12:09:51 +08:00
|
|
|
unsigned long flags;
|
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-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
|
|
|
|
2019-04-20 12:09:51 +08:00
|
|
|
batch = raw_cpu_ptr(&batched_entropy_u64);
|
|
|
|
spin_lock_irqsave(&batch->batch_lock, flags);
|
2017-01-22 23:34:08 +08:00
|
|
|
if (batch->position % ARRAY_SIZE(batch->entropy_u64) == 0) {
|
2018-09-12 11:05:10 +08:00
|
|
|
extract_crng((u8 *)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++];
|
2019-04-20 12:09:51 +08:00
|
|
|
spin_unlock_irqrestore(&batch->batch_lock, flags);
|
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
|
|
|
|
2019-04-20 12:09:51 +08:00
|
|
|
static DEFINE_PER_CPU(struct batched_entropy, batched_entropy_u32) = {
|
|
|
|
.batch_lock = __SPIN_LOCK_UNLOCKED(batched_entropy_u32.lock),
|
|
|
|
};
|
2017-01-22 23:34:08 +08:00
|
|
|
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;
|
2019-04-20 12:09:51 +08:00
|
|
|
unsigned long flags;
|
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
|
|
|
|
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
|
|
|
|
2019-04-20 12:09:51 +08:00
|
|
|
batch = raw_cpu_ptr(&batched_entropy_u32);
|
|
|
|
spin_lock_irqsave(&batch->batch_lock, flags);
|
2017-01-22 23:34:08 +08:00
|
|
|
if (batch->position % ARRAY_SIZE(batch->entropy_u32) == 0) {
|
2018-09-12 11:05:10 +08:00
|
|
|
extract_crng((u8 *)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++];
|
2019-04-20 12:09:51 +08:00
|
|
|
spin_unlock_irqrestore(&batch->batch_lock, flags);
|
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;
|
|
|
|
|
|
|
|
for_each_possible_cpu (cpu) {
|
2019-04-20 12:09:51 +08:00
|
|
|
struct batched_entropy *batched_entropy;
|
|
|
|
|
|
|
|
batched_entropy = per_cpu_ptr(&batched_entropy_u32, cpu);
|
|
|
|
spin_lock_irqsave(&batched_entropy->batch_lock, flags);
|
|
|
|
batched_entropy->position = 0;
|
|
|
|
spin_unlock(&batched_entropy->batch_lock);
|
|
|
|
|
|
|
|
batched_entropy = per_cpu_ptr(&batched_entropy_u64, cpu);
|
|
|
|
spin_lock(&batched_entropy->batch_lock);
|
|
|
|
batched_entropy->position = 0;
|
|
|
|
spin_unlock_irqrestore(&batched_entropy->batch_lock, flags);
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
*/
|
2019-11-17 08:48:17 +08:00
|
|
|
wait_event_interruptible(random_write_wait, kthread_should_stop() ||
|
2016-06-13 06:13:36 +08:00
|
|
|
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);
|
2019-08-23 14:24:51 +08:00
|
|
|
|
|
|
|
/* Handle random seed passed by bootloader.
|
|
|
|
* If the seed is trustworthy, it would be regarded as hardware RNGs. Otherwise
|
|
|
|
* it would be regarded as device data.
|
|
|
|
* The decision is controlled by CONFIG_RANDOM_TRUST_BOOTLOADER.
|
|
|
|
*/
|
|
|
|
void add_bootloader_randomness(const void *buf, unsigned int size)
|
|
|
|
{
|
|
|
|
if (IS_ENABLED(CONFIG_RANDOM_TRUST_BOOTLOADER))
|
|
|
|
add_hwgenerator_randomness(buf, size, size * 8);
|
|
|
|
else
|
|
|
|
add_device_randomness(buf, size);
|
|
|
|
}
|
2019-10-02 01:50:23 +08:00
|
|
|
EXPORT_SYMBOL_GPL(add_bootloader_randomness);
|