linux-toradex.git/drivers/char, branch v4.4.29

hwrng: omap - Only fail if pm_runtime_get_sync returns < 0

2016-10-31T10:14:00+00:00

commit ad8529fde9e3601180a839867a8ab041109aebb5 upstream.

Currently omap-rng checks the return value of pm_runtime_get_sync and
reports failure if anything is returned, however it should be checking
if ret < 0 as pm_runtime_get_sync return 0 on success but also can return
1 if the device was already active which is not a failure case. Only
values < 0 are actual failures.

Fixes: 61dc0a446e5d ("hwrng: omap - Fix assumption that runtime_get_sync will always succeed")
Signed-off-by: Dave Gerlach 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

tpm_crb: fix crb_req_canceled behavior

2016-10-16T15:36:15+00:00

commit 72fd50e14e46dc0edf360631bdece87c2f066a97 upstream.

The req_canceled() callback is used by tpm_transmit() periodically to
check whether the request has been canceled while it is receiving a
response from the TPM.

The TPM_CRB_CTRL_CANCEL register was cleared already in the crb_cancel
callback, which has two consequences:

* Cancel might not happen.
* req_canceled() always returns zero.

A better place to clear the register is when starting to send a new
command. The behavior of TPM_CRB_CTRL_CANCEL is described in the
section 5.5.3.6 of the PTP specification.

Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

tpm: fix a race condition in tpm2_unseal_trusted()

2016-10-16T15:36:15+00:00

commit d4816edfe706497a8525480c1685ceb9871bc118 upstream.

Unseal and load operations should be done as an atomic operation. This
commit introduces unlocked tpm_transmit() so that tpm2_unseal_trusted()
can do the locking by itself.

Fixes: 0fe5480303a1 ("keys, trusted: seal/unseal with TPM 2.0 chips")
Signed-off-by: Jarkko Sakkinen 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

hwrng: omap - Fix assumption that runtime_get_sync will always succeed

2016-10-07T13:23:44+00:00

commit 61dc0a446e5d08f2de8a24b45f69a1e302bb1b1b upstream.

pm_runtime_get_sync does return a error value that must be checked for
error conditions, else, due to various reasons, the device maynot be
enabled and the system will crash due to lack of clock to the hardware
module.

Before:
12.562784] [00000000] *pgd=fe193835
12.562792] Internal error: : 1406 [#1] SMP ARM
[...]
12.562864] CPU: 1 PID: 241 Comm: modprobe Not tainted 4.7.0-rc4-next-20160624 #2
12.562867] Hardware name: Generic DRA74X (Flattened Device Tree)
12.562872] task: ed51f140 ti: ed44c000 task.ti: ed44c000
12.562886] PC is at omap4_rng_init+0x20/0x84 [omap_rng]
12.562899] LR is at set_current_rng+0xc0/0x154 [rng_core]
[...]

After the proper checks:
[   94.366705] omap_rng 48090000.rng: _od_fail_runtime_resume: FIXME:
missing hwmod/omap_dev info
[   94.375767] omap_rng 48090000.rng: Failed to runtime_get device -19
[   94.382351] omap_rng 48090000.rng: initialization failed.

Fixes: 665d92fa85b5 ("hwrng: OMAP: convert to use runtime PM")
Cc: Paul Walmsley 
Signed-off-by: Nishanth Menon 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

tpm: fix byte-order for the value read by tpm2_get_tpm_pt

2016-10-07T13:23:43+00:00

commit 1b0612b04090e416828c0dd5ed197b0913d834a0 upstream.

The result must be converted from BE byte order, which is used by the
TPM2 protocol. This has not popped out because tpm2_get_tpm_pt() has
been only used for probing.

Fixes: 7a1d7e6dd76a ("tpm: TPM 2.0 baseline support")
Change-Id: I7d71cd379b1a3b7659d20a1b6008216762596590
Signed-off-by: Andrey Pronin 
Reviewed-by: Jason Gunthorpe 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Greg Kroah-Hartman

hwrng: exynos - Disable runtime PM on probe failure

2016-09-15T06:27:54+00:00

commit 48a61e1e2af8020f11a2b8f8dc878144477623c6 upstream.

Add proper error path (for disabling runtime PM) when registering of
hwrng fails.

Fixes: b329669ea0b5 ("hwrng: exynos - Add support for Exynos random number generator")
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

random: add interrupt callback to VMBus IRQ handler

2016-08-20T16:09:20+00:00

commit 4b44f2d18a330565227a7348844493c59366171e upstream.

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.

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

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

2016-08-20T16:09:20+00:00

commit 9b4d008787f864f17d008c9c15bbe8a0f7e2fc24 upstream.

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.

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

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

2016-08-20T16:09:20+00:00

commit 3371f3da08cff4b75c1f2dce742d460539d6566d upstream.

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.

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

random: strengthen input validation for RNDADDTOENTCNT

2016-08-16T07:30:49+00:00

commit 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec upstream.

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 
Signed-off-by: Greg Kroah-Hartman