kernel/linux.git/drivers/char/random.c, branch v3.15.2

random: fix BUG_ON caused by accounting simplification

2014-05-17T02:18:22+00:00

Commit ee1de406ba6eb1 ("random: simplify accounting logic") simplified things too much, in that it allows the following to trigger an overflow that results in a BUG_ON crash: dd if=/dev/urandom of=/dev/zero bs=67108707 count=1 Thanks to Peter Zihlstra for discovering the crash, and Hannes Frederic for analyizing the root cause. Signed-off-by: "Theodore Ts'o" Reported-by: Peter Zijlstra Reported-by: Hannes Frederic Sowa Cc: Greg Price

random: Add arch_has_random[_seed]()

2014-03-20T02:24:08+00:00

Add predicate functions for having arch_get_random[_seed]*(). The only current use is to avoid the loop in arch_random_refill() when arch_get_random_seed_long() is unavailable. Signed-off-by: H. Peter Anvin Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael Ellerman Signed-off-by: Theodore Ts'o

random: If we have arch_get_random_seed*(), try it before blocking

2014-03-20T02:22:06+00:00

If we have arch_get_random_seed*(), try to use it for emergency refill of the entropy pool before giving up and blocking on /dev/random. It may or may not work in the moment, but if it does work, it will give the user better service than blocking will. Reviewed-by: Ingo Molnar Signed-off-by: H. Peter Anvin Signed-off-by: Theodore Ts'o

random: Use arch_get_random_seed*() at init time and once a second

2014-03-20T02:22:06+00:00

Use arch_get_random_seed*() in two places in the Linux random driver (drivers/char/random.c): 1. During entropy pool initialization, use RDSEED in favor of RDRAND, with a fallback to the latter. Entropy exhaustion is unlikely to happen there on physical hardware as the machine is single-threaded at that point, but could happen in a virtual machine. In that case, the fallback to RDRAND will still provide more than adequate entropy pool initialization. 2. Once a second, issue RDSEED and, if successful, feed it to the entropy pool. To ensure an extra layer of security, only credit half the entropy just in case. Suggested-by: Linus Torvalds Reviewed-by: Ingo Molnar Signed-off-by: H. Peter Anvin Signed-off-by: Theodore Ts'o

random: use the architectural HWRNG for the SHA's IV in extract_buf()

2014-03-20T02:18:52+00:00

To help assuage the fears of those who think the NSA can introduce a massive hack into the instruction decode and out of order execution engine in the CPU without hundreds of Intel engineers knowing about it (only one of which woud need to have the conscience and courage of Edward Snowden to spill the beans to the public), use the HWRNG to initialize the SHA starting value, instead of xor'ing it in afterwards. Signed-off-by: "Theodore Ts'o"

random: clarify bits/bytes in wakeup thresholds

2014-03-20T02:18:51+00:00

These are a recurring cause of confusion, so rename them to hopefully be clearer. Signed-off-by: Greg Price Signed-off-by: "Theodore Ts'o"

random: entropy_bytes is actually bits

2014-03-20T02:18:51+00:00

The variable 'entropy_bytes' is set from an expression that actually counts bits. Fortunately it's also only compared to values that also count bits. Rename it accordingly. Signed-off-by: Greg Price Signed-off-by: "Theodore Ts'o"

random: simplify accounting code

2014-03-20T02:18:51+00:00

With this we handle "reserved" in just one place. As a bonus the code becomes less nested, and the "wakeup_write" flag variable becomes unnecessary. The variable "flags" was already unused. This code behaves identically to the previous version except in two pathological cases that don't occur. If the argument "nbytes" is already less than "min", then we didn't previously enforce "min". If r->limit is false while "reserved" is nonzero, then we previously applied "reserved" in checking whether we had enough bits, even though we don't apply it to actually limit how many we take. The callers of account() never exercise either of these cases. Before the previous commit, it was possible for "nbytes" to be less than "min" if userspace chose a pathological configuration, but no longer. Cc: Jiri Kosina Cc: "H. Peter Anvin" Signed-off-by: Greg Price Signed-off-by: "Theodore Ts'o"

random: tighten bound on random_read_wakeup_thresh

2014-03-20T02:18:51+00:00

We use this value in a few places other than its literal meaning, in particular in _xfer_secondary_pool() as a minimum number of bits to pull from the input pool at a time into either output pool. It doesn't make sense to pull more bits than the whole size of an output pool. We could and possibly should separate the quantities "how much should the input pool have to have to wake up /dev/random readers" and "how much should we transfer from the input to an output pool at a time", but nobody is likely to be sad they can't set the first quantity to more than 1024 bits, so for now just limit them both. Signed-off-by: Greg Price Signed-off-by: "Theodore Ts'o"

random: forget lock in lockless accounting

2014-03-20T02:18:51+00:00

The only mutable data accessed here is ->entropy_count, but since 10b3a32d2 ("random: fix accounting race condition") we use cmpxchg to protect our accesses to ->entropy_count here. Drop the use of the lock. Cc: Jiri Kosina Signed-off-by: Greg Price Signed-off-by: "Theodore Ts'o"