linux-stable.git/drivers/char, branch v3.16.3

tpm: Properly clean sysfs entries in error path

2014-09-17T16:21:52+00:00

commit b49e1043c48dac23f64fba684d31c4a96c1ffaa0 upstream.

Properly clean the sysfs entries in the error path

Reported-by: Dmitry Kasatkin 
Signed-off-by: Stefan Berger 
Reviewed-by: Jason Gunthorpe 
Signed-off-by: Peter Huewe 
Signed-off-by: Greg Kroah-Hartman

tpm: Provide a generic means to override the chip returned timeouts

2014-09-17T16:21:52+00:00

commit 8e54caf407b98efa05409e1fee0e5381abd2b088 upstream.

Some Atmel TPMs provide completely wrong timeouts from their
TPM_CAP_PROP_TIS_TIMEOUT query. This patch detects that and returns
new correct values via a DID/VID table in the TIS driver.

Tested on ARM using an AT97SC3204T FW version 37.16

[PHuewe: without this fix these 'broken' Atmel TPMs won't function on
older kernels]
Signed-off-by: "Berg, Christopher" 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Peter Huewe

tpm: missing tpm_chip_put in tpm_get_random()

2014-09-17T16:21:52+00:00

commit 3e14d83ef94a5806a865b85b513b4e891923c19b upstream.

Regression in 41ab999c. Call to tpm_chip_put is missing. This
will cause TPM device driver not to unload if tmp_get_random()
is called.

Signed-off-by: Jarkko Sakkinen 
Signed-off-by: Peter Huewe 
Signed-off-by: Greg Kroah-Hartman

tpm: Add missing tpm_do_selftest to ST33 I2C driver

2014-09-05T23:36:30+00:00

commit f07a5e9a331045e976a3d317ba43d14859d9407c upstream.

Most device drivers do call 'tpm_do_selftest' which executes a
TPM_ContinueSelfTest. tpm_i2c_stm_st33 is just pointlessly different,
I think it is bug.

These days we have the general assumption that the TPM is usable by
the kernel immediately after the driver is finished, so we can no
longer defer the mandatory self test to userspace.

Reported-by: Richard Marciel 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Peter Huewe 
Signed-off-by: Greg Kroah-Hartman

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

2014-07-19T06:26:46+00:00

Pull /dev/random fix from Ted Ts'o:
 "Fix a BUG splat found by trinity"

* tag 'random_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
  random: check for increase of entropy_count because of signed conversion

Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2014-07-19T06:25:54+00:00

Pull crypto fixes from Herbert Xu:
 "This push fixes a boot hang in virt guests when the virtio RNG is
  enabled"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  hwrng: virtio - ensure reads happen after successful probe
  hwrng: fetch randomness only after device init

random: check for increase of entropy_count because of signed conversion

2014-07-19T05:42:13+00:00

The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could
actually increase entropy_count if during assignment of the unsigned
expression on the RHS (mind the -=) we reduce the value modulo
2^width(int) and assign it to entropy_count. Trinity found this.

[ Commit modified by tytso to add an additional safety check for a
  negative entropy_count -- which should never happen, and to also add
  an additional paranoia check to prevent overly large count values to
  be passed into urandom_read().  ]

Reported-by: Dave Jones 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org

hwrng: virtio - ensure reads happen after successful probe

2014-07-14T12:48:17+00:00

The hwrng core asks for random data in the hwrng_register() call itself
from commit d9e7972619.  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 
CC: Jason Cooper 
CC: Herbert Xu 
CC:  # For v3.15+
Reviewed-by: Jason Cooper 
Signed-off-by: Amit Shah 
Signed-off-by: Herbert Xu

hwrng: fetch randomness only after device init

2014-07-14T12:48:17+00:00

Commit d9e7972619334 "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 
CC: Jason Cooper 
CC: Herbert Xu 
CC:  # For v3.15+
Signed-off-by: Amit Shah 
Reviewed-by: Jason Cooper 
Signed-off-by: Herbert Xu

i8k: Fix non-SMP operation

2014-07-09T23:45:36+00:00

Commit f36fdb9f0266 (i8k: Force SMM to run on CPU 0) adds support
for multi-core CPUs to the driver. Unfortunately, that causes it
to fail loading if compiled without SMP support, at least on
32 bit kernels. Kernel log shows "i8k: unable to get SMM Dell
signature", and function i8k_smm is found to return -EINVAL.

Testing revealed that the culprit is the missing return value check
of set_cpus_allowed_ptr.

Fixes: f36fdb9f0266 (i8k: Force SMM to run on CPU 0)
Reported-by: Jim Bos 
Tested-by: Jim Bos 
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Guenter Roeck 
Cc: Andreas Mohr 
Signed-off-by: Greg Kroah-Hartman