kernel.git/drivers/char/hw_random/core.c, branch linux-5.4.y

hwrng: core - Fix page fault dead lock on mmap-ed hwrng

2024-02-23T07:24:48Z

commit 78aafb3884f6bc6636efcc1760c891c8500b9922 upstream. There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user. Reported-by: Edward Adam Davis Reported-by: syzbot+c52ab18308964d248092@syzkaller.appspotmail.com Fixes: 9996508b3353 ("hwrng: core - Replace u32 in driver API with byte array") Cc: Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

random: pull add_hwgenerator_randomness() declaration into random.h

2022-06-22T12:11:12Z

commit b777c38239fec5a528e59f55b379e31b1a187524 upstream. add_hwgenerator_randomness() is a function implemented and documented inside of random.c. It is the way that hardware RNGs push data into it. Therefore, it should be declared in random.h. Otherwise sparse complains with: random.c:1137:6: warning: symbol 'add_hwgenerator_randomness' was not declared. Should it be static? The alternative would be to include hw_random.h into random.c, but that wouldn't really be good for anything except slowing down compile time. Cc: Matt Mackall Cc: Theodore Ts'o Acked-by: Herbert Xu Reviewed-by: Eric Biggers Reviewed-by: Dominik Brodowski Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman

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

2019-11-17T00:48:17Z

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 - don't wait on add_early_randomness()

2019-09-20T13:05:33Z

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:13Z

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:02Z

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:56Z

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:49Z

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:36Z

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

hwrng: core - Reset user selected rng by writing "" to rng_current

2017-11-03T14:11:25Z

User is able to select a chosen rng by writing its name to rng_current but there is no way to reset it without unbinding the rng. Let user write "" to rng_current and delesect the chosen rng. Signed-off-by: PrasannaKumar Muralidharan reviewed-by: Harald Freudenberger Signed-off-by: Herbert Xu