This patch fix the checkpatch warning about asm/uaccess.h.
In the same time, we sort the headers in alphabetical order.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

checkpatch have lot of complaint about header.
Furthermore, the header have some offtopic/useless information.

This patch rewrite a proper header.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch fix the checkpatch warning "Comparison to NULL could be written "!ptr"
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch fix the checkpatch warning "Please don't use multiple blank lines"
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This was entirely automated, using the script by Al:

  PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*<asm/uaccess.h>'
  sed -i -e "s!$PATT!#include <linux/uaccess.h>!" \
        $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h)

to do the replacement at the end of the merge window.
Requested-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The HWRNG core allocates two buffers during initialization which are
used to obtain random data. After that data is processed, it is now
zeroized as it is possible that the HWRNG core will not be asked to
produce more random data for a long time. This prevents leaving such
sensitive data in memory.
Signed-off-by: NStephan Mueller <smueller@chronox.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

hw_random carefully avoids using a stack buffer except in
add_early_randomness().  This causes a crash in virtio_rng if
CONFIG_VMAP_STACK=y.
Reported-by: NMatt Mullins <mmullins@mmlx.us>
Tested-by: NMatt Mullins <mmullins@mmlx.us>
Fixes: d3cc7996 ("hwrng: fetch randomness only after device init")
Signed-off-by: NAndy Lutomirski <luto@kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In core rng_buffer and rng_fillbuf is allocated in hwrng_register only
once and it is freed during module exit. This patch moves allocating
rng_buffer and rng_fillbuf from hwrng_register to rng core's init. This
avoids checking whether rng_buffer and rng_fillbuf was allocated from
every hwrng_register call. Also moving them to module init makes it
explicit that it is freed in module exit.

Change in v2:
Fix memory leak when register_miscdev fails.
Signed-off-by: NPrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

hwrng kthread can be waiting via hwrng_fillfn for some data from a rng
like virtio-rng:
hwrng           D ffff880093e17798     0   382      2 0x00000000
...
Call Trace:
 [<ffffffff817339c6>] wait_for_completion_killable+0x96/0x210
 [<ffffffffa00aa1b7>] virtio_read+0x57/0xf0 [virtio_rng]
 [<ffffffff814f4a35>] hwrng_fillfn+0x75/0x130
 [<ffffffff810aa243>] kthread+0xf3/0x110

And when some user program tries to read the /dev node in this state,
we get:
rngd            D ffff880093e17798     0   762      1 0x00000004
...
Call Trace:
 [<ffffffff817351ac>] mutex_lock_nested+0x15c/0x3e0
 [<ffffffff814f478e>] rng_dev_read+0x6e/0x240
 [<ffffffff81231958>] __vfs_read+0x28/0xe0
 [<ffffffff81232393>] vfs_read+0x83/0x130

And this is indeed unkillable. So use mutex_lock_interruptible
instead of mutex_lock in rng_dev_read and exit immediatelly when
interrupted. And possibly return already read data, if any (as POSIX
allows).

v2: use ERESTARTSYS instead of EINTR
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: <linux-crypto@vger.kernel.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

If we attempt to use sysfs to change the current RNG in the usual
way i.e. issuing something like:

`echo 8a8a000.rng > /sys/devices/virtual/misc/hw_random/rng_current`

... it will fail because the code doesn't currently take the '\n'
into consideration.  Well, now it does.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NPeter Korsgaard <peter@korsgaard.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The kthread_run() function can return two different error values
but the hwrng core only checks for -ENOMEM. If the other error
value -EINTR is returned it is assigned to hwrng_fill and later
used on a kthread_stop() call which naturally crashes.

Cc: stable@vger.kernel.org
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Use the new group field of struct miscdevice for managing the sysfs
entries instead of manually adding/removing via device_create_file()
and device_remove_file().  This simplifies the code a lot and fixes
the possible races.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Hardware random number quality is measured from 0 (no entropy) to 1024
(perfect entropy). Allow hardware devices to assert the full range by
truncating the device-provided value at 1024 instead of 1023.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This change adds devm_hwrng_register and devm_hwrng_unregister which
use can simplify error unwinding and unbinding code paths in device
drivers.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We always do hwrng_init in set_current_rng.  In fact, our current
reference count system relies on this.  So make this explicit by
moving hwrng_init into set_current_rng.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Rather than having callers of set_current_rng call drop_current_rng,
we can do it directly in set_current_rng.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Currently we only register the device when a valid RNG is added.
However the way it's done is buggy because we test whether there
is a current RNG to determine whether we need to register.  As
the current RNG may be missing due to a reinitialisation error
this can lead to a reregistration of the device.

As the device already has to handle a NULL current RNG anyway,
let's just register the device always and remove the complexity.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The kref solution is still buggy because we were only focusing
on the register/unregister race.  The same race affects the
setting of current_rng through sysfs.

This patch fixes it by using kref_get_unless_zero.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

There is no point in doing a manual completion for cleanup_done
when struct completion fits in perfectly.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Another interesting anti-pattern.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Interesting anti-pattern.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The previous patch added one potential problem: we can still be
reading from a hwrng when it's unregistered.  Add a wait for zero
in the hwrng_unregister path.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

current_rng holds one reference, and we bump it every time we want
to do a read from it.

This means we only hold the rng_mutex to grab or drop a reference,
so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't
block on read of /dev/hwrng.

Using a kref is overkill (we're always under the rng_mutex), but
a standard pattern.

This also solves the problem that the hwrng_fillfn thread was
accessing current_rng without a lock, which could change (eg. to NULL)
underneath it.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

In next patch, we use reference counting for each struct hwrng,
changing reference count also needs to take mutex_lock. Before
releasing the lock, if we try to stop a kthread that waits to
take the lock to reduce the referencing count, deadlock will
occur.
Signed-off-by: NAmos Kong <akong@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

There's currently a big lock around everything, and it means that we
can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current)
while the rng is reading.  This is a real problem when the rng is slow,
or blocked (eg. virtio_rng with qemu's default /dev/random backend)

This doesn't help (it leaves the current lock untouched), just adds a
lock to protect the read function and the static buffers, in preparation
for transition.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The buf is used to hold the list of hwrng devices registered.
The old code ensures we don't walk off the end of buf as we
fill it, but it's unnecessarily complicated and thus difficult
to maintain. Simplify it by using strlcat.
Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Reviewed-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

rng_get_data() returns the number of bytes read from the hardware.
The entropy argument to add_hwgenerator_randomness() is passed
directly to credit_entropy_bits() so we should be passing the
number of bits, not bytes here.

Fixes: be4000bc "hwrng: create filler thread"
Acked-by: NTorsten Duwe <duwe@suse.de>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

This reverts commit e052dbf5.

Now that we use the virtio ->scan() function to register with the hwrng
core, we will not get read requests till probe is successfully finished.

So revert the workaround we had in place to refuse read requests while
we were not yet setup completely.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Signed-off-by: NTorsten Duwe <duwe@suse.de>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>

This patch introduces a derating factor to struct hwrng for
the random bits going into the kernel input pool, and a common
default derating for drivers which do not specify one.
Signed-off-by: NTorsten Duwe <duwe@suse.de>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Acked-by: NH. Peter Anvin <hpa@zytor.com>

This can be viewed as the in-kernel equivalent of hwrngd;
like FUSE it is a good thing to have a mechanism in user land,
but for some reasons (simplicity, secrecy, integrity, speed)
it may be better to have it in kernel space.

This patch creates a thread once a hwrng registers, and uses
the previously established add_hwgenerator_randomness() to feed
its data to the input pool as long as needed. A derating factor
is used to bias the entropy estimation and to disable this
mechanism entirely when set to zero.
Signed-off-by: NTorsten Duwe <duwe@suse.de>
Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
Acked-by: NH. Peter Anvin <hpa@zytor.com>

The hwrng core asks for random data in the hwrng_register() call itself
from commit d9e79726.  This doesn't play well with virtio -- the
DRIVER_OK bit is only set by virtio core on a successful probe, and
we're not yet out of our probe routine when this call is made.  This
causes the host to not acknowledge any requests we put in the virtqueue,
and the insmod or kernel boot process just waits for data to arrive from
the host, which never happens.

CC: Kees Cook <keescook@chromium.org>
CC: Jason Cooper <jason@lakedaemon.net>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: <stable@vger.kernel.org> # For v3.15+
Reviewed-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Commit d9e79726 "hwrng: add randomness to system from rng sources"
added a call to rng_get_data() from the hwrng_register() function.
However, some rng devices need initialization before data can be read
from them.

This commit makes the call to rng_get_data() depend on no init fn
pointer being registered by the device.  If an init function is
registered, this call is made after device init.

CC: Kees Cook <keescook@chromium.org>
CC: Jason Cooper <jason@lakedaemon.net>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: <stable@vger.kernel.org> # For v3.15+
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Reviewed-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

When bringing a new RNG source online, it seems like it would make sense
to use some of its bytes to make the system entropy pool more random,
as done with all sorts of other devices that contain per-device or
per-boot differences.
Signed-off-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NJason Cooper <jason@lakedaemon.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

My static checker complains that:

	drivers/char/hw_random/core.c:341 hwrng_register()
	warn: we tested 'old_rng' before and it was 'false'

The problem is that sometimes we test "if (!old_rng)" and sometimes we
test "if (must_register_misc)".  The static checker knows they are
equivalent but a human being reading the code could easily be confused.

I have simplified the code by removing the "must_register_misc" variable
and I have removed the redundant check on "if (!old_rng)".
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>.  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

Cc: David Airlie <airlied@linux.ie>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Corey Minyard <minyard@acm.org>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Peter Huewe <peterhuewe@gmx.de>
Cc: Ashley Lai <ashley@ashleylai.com>
Cc: Marcel Selhorst <tpmdd@selhorst.net>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

rng-core module allocates rng_buffer by kmalloc() since commit
f7f154f1. But this buffer won't be
freed and there is a memory leak possibility at module exit.
Signed-off-by: NSatoru Takeuchi <satoru.takeuchi@gmail.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

virtio_rng feeds the randomness buffer handed by the core directly
into the scatterlist, since commit bb347d98.

However, if CONFIG_HW_RANDOM=m, the static buffer isn't a linear address
(at least on most archs).  We could fix this in virtio_rng, but it's actually
far easier to just do it in the core as virtio_rng would have to allocate
a buffer every time (it doesn't know how much the core will want to read).
Reported-by: NAurelien Jarno <aurelien@aurel32.net>
Tested-by: NAurelien Jarno <aurelien@aurel32.net>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org

Signed-off-by: NMichael Buesch <m@bues.ch>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The big kernel lock has been removed from all these files at some point,
leaving only the #include.

Remove this too as a cleanup.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>