linux-toradex.git/drivers/char/random.c, branch v3.10.78

random: add and use memzero_explicit() for clearing data

2014-11-14T16:47:55+00:00

commit d4c5efdb97773f59a2b711754ca0953f24516739 upstream.

zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
memset() calls which clear out sensitive data in extract_{buf,entropy,
entropy_user}() in random driver are being optimized away by gcc.

Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
that can be used in such cases where a variable with sensitive data is
being cleared out in the end. Other use cases might also be in crypto
code. [ I have put this into lib/string.c though, as it's always built-in
and doesn't need any dependencies then. ]

Fixes kernel bugzilla: 82041

Reported-by: zatimend@hotmail.co.uk
Signed-off-by: Daniel Borkmann 
Acked-by: Hannes Frederic Sowa 
Cc: Alexey Dobriyan 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

random: run random_int_secret_init() run after all late_initcalls

2013-10-18T14:45:44+00:00

commit 47d06e532e95b71c0db3839ebdef3fe8812fca2c upstream.

The some platforms (e.g., ARM) initializes their clocks as
late_initcalls for some unknown reason.  So make sure
random_int_secret_init() is run after all of the late_initcalls are
run.

Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

random: fix accounting race condition with lockless irq entropy_count update

2013-05-24T23:22:52+00:00

Commit 902c098a3663 ("random: use lockless techniques in the interrupt
path") turned IRQ path from being spinlock protected into lockless
cmpxchg-retry update.

That commit removed r->lock serialization between crediting entropy bits
from IRQ context and accounting when extracting entropy on userspace
read path, but didn't turn the r->entropy_count reads/updates in
account() to use cmpxchg as well.

It has been observed, that under certain circumstances this leads to
read() on /dev/urandom to return 0 (EOF), as r->entropy_count gets
corrupted and becomes negative, which in turn results in propagating 0
all the way from account() to the actual read() call.

Convert the accounting code to be the proper lockless counterpart of
what has been partially done by 902c098a3663.

Signed-off-by: Jiri Kosina 
Cc: Theodore Ts'o 
Cc: Greg KH 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

drivers/char/random.c: fix priming of last_data

2013-05-24T23:22:52+00:00

Commit ec8f02da9ea5 ("random: prime last_data value per fips
requirements") added priming of last_data per fips requirements.

Unfortuantely, it did so in a way that can lead to multiple threads all
incrementing nbytes, but only one actually doing anything with the extra
data, which leads to some fun random corruption and panics.

The fix is to simply do everything needed to prime last_data in a single
shot, so there's no window for multiple cpus to increment nbytes -- in
fact, we won't even increment or decrement nbytes anymore, we'll just
extract the needed EXTRACT_SIZE one time per pool and then carry on with
the normal routine.

All these changes have been tested across multiple hosts and
architectures where panics were previously encoutered.  The code changes
are are strictly limited to areas only touched when when booted in fips
mode.

This change should also go into 3.8-stable, to make the myriads of fips
users on 3.8.x happy.

Signed-off-by: Jarod Wilson 
Tested-by: Jan Stancek 
Tested-by: Jan Stodola 
Cc: Herbert Xu 
Acked-by: Neil Horman 
Cc: "David S. Miller" 
Cc: Matt Mackall 
Cc: "Theodore Ts'o" 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/string_helpers: introduce generic string_unescape

2013-05-01T00:04:03+00:00

There are several places in kernel where modules unescapes input to convert
C-Style Escape Sequences into byte codes.

The patch provides generic implementation of such approach. Test cases are
also included into the patch.

[akpm@linux-foundation.org: clarify comment]
[akpm@linux-foundation.org: export get_random_int() to modules]
Signed-off-by: Andy Shevchenko 
Cc: Samuel Thibault 
Cc: Greg Kroah-Hartman 
Cc: Jason Baron 
Cc: Alexander Viro 
Cc: William Hubbs 
Cc: Chris Brannon 
Cc: Kirk Reiser 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random

2013-03-08T22:42:16+00:00

Pull random fixes from Ted Ts'o:
 "Fix a circular locking dependency in random's collection of cputime
  used by a thread when it exits."

* tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
  random: fix locking dependency with the tasklist_lock

random: fix locking dependency with the tasklist_lock

2013-03-04T17:05:15+00:00

Commit 6133705494bb introduced a circular lock dependency because
posix_cpu_timers_exit() is called by release_task(), which is holding
a writer lock on tasklist_lock, and this can cause a deadlock since
kill_fasync() gets called with nonblocking_pool.lock taken.

There's no reason why kill_fasync() needs to be taken while the random
pool is locked, so move it out to fix this locking dependency.

Signed-off-by: "Theodore Ts'o" 
Reported-by: Russ Dill 
Cc: stable@kernel.org

locking: Various static lock initializer fixes

2013-02-19T07:42:45+00:00

The static lock initializers want to be fed the proper name of the
lock and not some random string. In mainline random strings are
obfuscating the readability of debug output, but for RT they prevent
the spinlock substitution. Fix it up.

Signed-off-by: Thomas Gleixner

random: prime last_data value per fips requirements

2012-11-08T12:19:18+00:00

The value stored in last_data must be primed for FIPS 140-2 purposes. Upon
first use, either on system startup or after an RNDCLEARPOOL ioctl, we
need to take an initial random sample, store it internally in last_data,
then pass along the value after that to the requester, so that consistency
checks aren't being run against stale and possibly known data.

CC: Herbert Xu 
CC: "David S. Miller" 
CC: Matt Mackall 
CC: linux-crypto@vger.kernel.org
Acked-by: Neil Horman 
Signed-off-by: Jarod Wilson 
Signed-off-by: "Theodore Ts'o"

random: fix debug format strings

2012-11-08T12:12:20+00:00

Fix the following warnings in formatting debug output:

drivers/char/random.c: In function ‘xfer_secondary_pool’:
drivers/char/random.c:827: warning: format ‘%d’ expects type ‘int’, but argument 7 has type ‘size_t’
drivers/char/random.c: In function ‘account’:
drivers/char/random.c:859: warning: format ‘%d’ expects type ‘int’, but argument 5 has type ‘size_t’
drivers/char/random.c:881: warning: format ‘%d’ expects type ‘int’, but argument 5 has type ‘size_t’
drivers/char/random.c: In function ‘random_read’:
drivers/char/random.c:1141: warning: format ‘%d’ expects type ‘int’, but argument 5 has type ‘ssize_t’
drivers/char/random.c:1145: warning: format ‘%d’ expects type ‘int’, but argument 5 has type ‘ssize_t’
drivers/char/random.c:1145: warning: format ‘%d’ expects type ‘int’, but argument 6 has type ‘long unsigned int’

by using '%zd' instead of '%d' to properly denote ssize_t/size_t conversion.

Signed-off-by: Jiri Kosina 
Signed-off-by: Theodore Ts'o