linux-toradex.git/drivers/char/random.c, branch v4.8-rc1

random: Fix crashes with sparse node ids

2016-07-31T04:00:06+00:00

On a system with sparse node ids, eg. a powerpc system with 4 nodes
numbered like so:

  node   0: [mem 0x0000000000000000-0x00000007ffffffff]
  node   1: [mem 0x0000000800000000-0x0000000fffffffff]
  node  16: [mem 0x0000001000000000-0x00000017ffffffff]
  node  17: [mem 0x0000001800000000-0x0000001fffffffff]

The code in rand_initialize() will allocate 4 pointers for the pool
array, and initialise them correctly.

However when go to use the pool, in eg. extract_crng(), we use the
numa_node_id() to index into the array. For the higher numbered node ids
this leads to random memory corruption, depending on what was kmalloc'ed
adjacent to the pool array.

Fix it by using nr_node_ids to size the pool array.

Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly userspace programs")
Signed-off-by: Michael Ellerman 
Signed-off-by: Linus Torvalds

random: use for_each_online_node() to iterate over NUMA nodes

2016-07-28T03:30:25+00:00

This fixes a crash on s390 with fake NUMA enabled.

Reported-by: Heiko Carstens 
Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly userspace programs")
Signed-off-by: Theodore Ts'o

random: strengthen input validation for RNDADDTOENTCNT

2016-07-03T21:09:33+00:00

Don't allow RNDADDTOENTCNT or RNDADDENTROPY to accept a negative
entropy value.  It doesn't make any sense to subtract from the entropy
counter, and it can trigger a warning:

random: negative entropy/overflow: pool input count -40000
------------[ cut here ]------------
WARNING: CPU: 3 PID: 6828 at drivers/char/random.c:670[<      none
 >] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
Modules linked in:
CPU: 3 PID: 6828 Comm: a.out Not tainted 4.7.0-rc4+ #4
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 ffffffff880b58e0 ffff88005dd9fcb0 ffffffff82cc838f ffffffff87158b40
 fffffbfff1016b1c 0000000000000000 0000000000000000 ffffffff87158b40
 ffffffff83283dae 0000000000000009 ffff88005dd9fcf8 ffffffff8136d27f
Call Trace:
 [<     inline     >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x12e/0x18f lib/dump_stack.c:51
 [] __warn+0x19f/0x1e0 kernel/panic.c:516
 [] warn_slowpath_null+0x2c/0x40 kernel/panic.c:551
 [] credit_entropy_bits+0x21e/0xad0 drivers/char/random.c:670
 [<     inline     >] credit_entropy_bits_safe drivers/char/random.c:734
 [] random_ioctl+0x21d/0x250 drivers/char/random.c:1546
 [<     inline     >] vfs_ioctl fs/ioctl.c:43
 [] do_vfs_ioctl+0x18c/0xff0 fs/ioctl.c:674
 [<     inline     >] SYSC_ioctl fs/ioctl.c:689
 [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
 [] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207
---[ end trace 5d4902b2ba842f1f ]---

This was triggered using the test program:

// autogenerated by syzkaller (http://github.com/google/syzkaller)

int main() {
        int fd = open("/dev/random", O_RDWR);
        int val = -5000;
        ioctl(fd, RNDADDTOENTCNT, &val);
        return 0;
}

It's harmless in that (a) only root can trigger it, and (b) after
complaining the code never does let the entropy count go negative, but
it's better to simply not allow this userspace from passing in a
negative entropy value altogether.

Google-Bug-Id: #29575089
Reported-By: Dmitry Vyukov 
Signed-off-by: Theodore Ts'o

random: add backtracking protection to the CRNG

2016-07-03T04:58:01+00:00

Signed-off-by: Theodore Ts'o

random: make /dev/urandom scalable for silly userspace programs

2016-07-03T04:57:58+00:00

On a system with a 4 socket (NUMA) system where a large number of
application threads were all trying to read from /dev/urandom, this
can result in the system spending 80% of its time contending on the
global urandom spinlock.  The application should have used its own
PRNG, but let's try to help it from running, lemming-like, straight
over the locking cliff.

Reported-by: Andi Kleen 
Signed-off-by: Theodore Ts'o

random: replace non-blocking pool with a Chacha20-based CRNG

2016-07-03T04:57:23+00:00

The CRNG is faster, and we don't pretend to track entropy usage in the
CRNG any more.

Signed-off-by: Theodore Ts'o

random: properly align get_random_int_hash

2016-06-13T15:54:34+00:00

get_random_long() reads from the get_random_int_hash array using an
unsigned long pointer.  For this code to be guaranteed correct on all
architectures, the array must be aligned to an unsigned long boundary.

Cc: stable@kernel.org
Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o

random: add interrupt callback to VMBus IRQ handler

2016-06-13T15:54:33+00:00

The Hyper-V Linux Integration Services use the VMBus implementation for
communication with the Hypervisor. VMBus registers its own interrupt
handler that completely bypasses the common Linux interrupt handling.
This implies that the interrupt entropy collector is not triggered.

This patch adds the interrupt entropy collection callback into the VMBus
interrupt handler function.

Cc: stable@kernel.org
Signed-off-by: Stephan Mueller 
Signed-off-by: Stephan Mueller 
Signed-off-by: Theodore Ts'o

random: print a warning for the first ten uninitialized random users

2016-06-13T15:54:26+00:00

Since systemd is consistently using /dev/urandom before it is
initialized, we can't see the other potentially dangerous users of
/dev/urandom immediately after boot.  So print the first ten such
complaints instead.

Cc: stable@kernel.org
Signed-off-by: Theodore Ts'o

random: initialize the non-blocking pool via add_hwgenerator_randomness()

2016-06-13T15:15:17+00:00

If we have a hardware RNG and are using the in-kernel rngd, we should
use this to initialize the non-blocking pool so that getrandom(2)
doesn't block unnecessarily.

Cc: stable@kernel.org
Signed-off-by: Theodore Ts'o