linux.git/drivers/char/hw_random/core.c, branch v5.8

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

2019-11-26T03:49:58+00:00

Pull crypto updates from Herbert Xu:
 "API:
   - Add library interfaces of certain crypto algorithms for WireGuard
   - Remove the obsolete ablkcipher and blkcipher interfaces
   - Move add_early_randomness() out of rng_mutex

  Algorithms:
   - Add blake2b shash algorithm
   - Add blake2s shash algorithm
   - Add curve25519 kpp algorithm
   - Implement 4 way interleave in arm64/gcm-ce
   - Implement ciphertext stealing in powerpc/spe-xts
   - Add Eric Biggers's scalar accelerated ChaCha code for ARM
   - Add accelerated 32r2 code from Zinc for MIPS
   - Add OpenSSL/CRYPTOGRAMS poly1305 implementation for ARM and MIPS

  Drivers:
   - Fix entropy reading failures in ks-sa
   - Add support for sam9x60 in atmel
   - Add crypto accelerator for amlogic GXL
   - Add sun8i-ce Crypto Engine
   - Add sun8i-ss cryptographic offloader
   - Add a host of algorithms to inside-secure
   - Add NPCM RNG driver
   - add HiSilicon HPRE accelerator
   - Add HiSilicon TRNG driver"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (285 commits)
  crypto: vmx - Avoid weird build failures
  crypto: lib/chacha20poly1305 - use chacha20_crypt()
  crypto: x86/chacha - only unregister algorithms if registered
  crypto: chacha_generic - remove unnecessary setkey() functions
  crypto: amlogic - enable working on big endian kernel
  crypto: sun8i-ce - enable working on big endian
  crypto: mips/chacha - select CRYPTO_SKCIPHER, not CRYPTO_BLKCIPHER
  hwrng: ks-sa - Enable COMPILE_TEST
  crypto: essiv - remove redundant null pointer check before kfree
  crypto: atmel-aes - Change data type for "lastc" buffer
  crypto: atmel-tdes - Set the IV after {en,de}crypt
  crypto: sun4i-ss - fix big endian issues
  crypto: sun4i-ss - hide the Invalid keylen message
  crypto: sun4i-ss - use crypto_ahash_digestsize
  crypto: sun4i-ss - remove dependency on not 64BIT
  crypto: sun4i-ss - Fix 64-bit size_t warnings on sun4i-ss-hash.c
  MAINTAINERS: Add maintainer for HiSilicon SEC V2 driver
  crypto: hisilicon - add DebugFS for HiSilicon SEC
  Documentation: add DebugFS doc for HiSilicon SEC
  crypto: hisilicon - add SRIOV for HiSilicon SEC
  ...

Revert "hwrng: core - Freeze khwrng thread during suspend"

2019-11-17T00:48:17+00:00

This reverts commit 03a3bb7ae631 ("hwrng: core - Freeze khwrng
thread during suspend"), ff296293b353 ("random: Support freezable
kthreads in add_hwgenerator_randomness()") and 59b569480dc8 ("random:
Use wait_event_freezable() in add_hwgenerator_randomness()").

These patches introduced regressions and we need more time to
get them ready for mainline.

Signed-off-by: Herbert Xu

hwrng: core - Fix use-after-free warning in hwrng_register()

2019-10-23T08:47:00+00:00

Commit daae28debcb0 has moved add_early_randomness() out of the
rng_mutex and tries to protect the reference of the new rng device
by incrementing the reference counter.

But in hwrng_register(), the function can be called with a new device
that is not set as the current_rng device and the reference has not been
initialized. This patch fixes the problem by not using the reference
counter when the device is not the current one: the reference counter
is only meaningful in the case of the current rng device and a device
is not used if it is not the current one (except in hwrng_register())

The problem has been reported by Marek Szyprowski on ARM 32bit
Exynos5420-based Chromebook Peach-Pit board:

WARNING: CPU: 3 PID: 1 at lib/refcount.c:156 hwrng_register+0x13c/0x1b4
refcount_t: increment on 0; use-after-free.
Modules linked in:
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00061-gdaae28debcb0
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xa8/0xd4)
[] (dump_stack) from [] (__warn+0xf4/0x10c)
[] (__warn) from [] (warn_slowpath_fmt+0x74/0xb8)
[] (warn_slowpath_fmt) from [] (hwrng_register+0x13c/0x1b4)
[] (hwrng_register) from [] (tpm_chip_register+0xc4/0x274)
...

Reported-by: Marek Szyprowski 
Fixes: daae28debcb0 ("hwrng: core - move add_early_randomness() out of rng_mutex")
Tested-by: Marek Szyprowski 
Signed-off-by: Laurent Vivier 
Signed-off-by: Herbert Xu

hwrng: core - move add_early_randomness() out of rng_mutex

2019-10-10T12:36:31+00:00

add_early_randomness() is called every time a new rng backend is added
and every time it is set as the current rng provider.

add_early_randomness() is called from functions locking rng_mutex,
and if it hangs all the hw_random framework hangs: we can't read sysfs,
add or remove a backend.

This patch move add_early_randomness() out of the rng_mutex zone.
It only needs the reading_mutex.

Signed-off-by: Laurent Vivier 
Signed-off-by: Herbert Xu

hwrng: core - don't wait on add_early_randomness()

2019-09-20T13:05:33+00:00

add_early_randomness() is called by hwrng_register() when the
hardware is added. If this hardware and its module are present
at boot, and if there is no data available the boot hangs until
data are available and can't be interrupted.

For instance, in the case of virtio-rng, in some cases the host can be
not able to provide enough entropy for all the guests.

We can have two easy ways to reproduce the problem but they rely on
misconfiguration of the hypervisor or the egd daemon:

- if virtio-rng device is configured to connect to the egd daemon of the
host but when the virtio-rng driver asks for data the daemon is not
connected,

- if virtio-rng device is configured to connect to the egd daemon of the
host but the egd daemon doesn't provide data.

The guest kernel will hang at boot until the virtio-rng driver provides
enough data.

To avoid that, call rng_get_data() in non-blocking mode (wait=0)
from add_early_randomness().

Signed-off-by: Laurent Vivier 
Fixes: d9e797261933 ("hwrng: add randomness to system from rng...")
Cc: 
Reviewed-by: Theodore Ts'o 
Signed-off-by: Herbert Xu

hwrng: core - Freeze khwrng thread during suspend

2019-08-15T11:52:13+00:00

The hwrng_fill() function can run while devices are suspending and
resuming. If the hwrng is behind a bus such as i2c or SPI and that bus
is suspended, the hwrng may hang the bus while attempting to add some
randomness. It's been observed on ChromeOS devices with suspend-to-idle
(s2idle) and an i2c based hwrng that this kthread may run and ask the
hwrng device for randomness before the i2c bus has been resumed.

Let's make this kthread freezable so that we don't try to touch the
hwrng during suspend/resume. This ensures that we can't cause the hwrng
backing driver to get into a bad state because the device is guaranteed
to be resumed before the hwrng kthread is thawed.

Cc: Andrey Pronin 
Cc: Duncan Laurie 
Cc: Jason Gunthorpe 
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Guenter Roeck 
Cc: Alexander Steffen 
Signed-off-by: Stephen Boyd 
Signed-off-by: Herbert Xu

docs: admin-guide: add a series of orphaned documents

2019-07-15T14:03:02+00:00

There are lots of documents that belong to the admin-guide but
are on random places (most under Documentation root dir).

Move them to the admin guide.

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Alexandre Belloni 
Acked-by: Bartlomiej Zolnierkiewicz

hwrng: core - document the quality field

2018-10-05T02:16:56+00:00

quality field is currently documented as being 'per mill'.  In fact the
math involved is:

                add_hwgenerator_randomness((void *)rng_fillbuf, rc,
                                           rc * current_quality * 8 >> 10);

thus the actual definition is "bits of entropy per 1024 bits of input".

The current documentation seems to have confused multiple people
in the past, let's fix the documentation to match code.

An alternative is to change core to match driver expectations, replacing
	rc * current_quality * 8 >> 10
with
	rc * current_quality / 1000
but that has performance costs, so probably isn't a good option.

Fixes: 0f734e6e768 ("hwrng: add per-device entropy derating")
Reported-by: "Dr. David Alan Gilbert" 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: Herbert Xu

hwrng: core - Always drop the RNG in hwrng_unregister()

2018-06-15T15:06:49+00:00

enable_best_rng() is used in hwrng_unregister() to switch away from the
currently active RNG, if that is the one currently being removed.
However enable_best_rng() might fail, if the next RNG's init routine
fails. In that case enable_best_rng() will return an error code and
the currently active RNG will remain active.
After unregistering this might lead to crashes due to use-after-free.

Fix this by dropping the currently active RNG, if enable_best_rng()
failed. This will result in no RNG to be active, if the next-best
one failed to initialize.

This problem was introduced by 142a27f0a731ddcf467546960a5585970ca98e21

Fixes: 142a27f0a731 ("hwrng: core - Reset user selected rng by...")
Reported-by: Wirz 
Tested-by: Wirz 
Signed-off-by: Michael Büsch 
Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu

hwrng: core - Clean up RNG list when last hwrng is unregistered

2017-12-22T09:03:36+00:00

Commit 142a27f0a731 added support for a "best" RNG, and in doing so
introduced a hang from rmmod/modprobe -r when the last RNG on the list
was unloaded.

When the hwrng list is depleted, return the global variables to their
original state and decrement all references to the object.

Fixes: 142a27f0a731 ("hwrng: core - Reset user selected rng by writing "" to rng_current")
Signed-off-by: Gary R Hook 
Reviewed-by: PrasannaKumar Muralidharan 
Signed-off-by: Herbert Xu