kernel/linux.git/include/linux/hw_random.h, branch v6.6.131

hwrng: bcm2835 - Fix hwrng throughput regression

2023-11-20T10:59:18+00:00

[ Upstream commit b58a36008bfa1aadf55f516bcbfae40c779eb54b ] The last RCU stall fix caused a massive throughput regression of the hwrng on Raspberry Pi 0 - 3. hwrng_msleep doesn't sleep precisely enough and usleep_range doesn't allow scheduling. So try to restore the best possible throughput by introducing hwrng_yield which interruptable sleeps for one jiffy. Some performance measurements on Raspberry Pi 3B+ (arm64/defconfig): sudo dd if=/dev/hwrng of=/dev/null count=1 bs=10000 cpu_relax ~138025 Bytes / sec hwrng_msleep(1000) ~13 Bytes / sec hwrng_yield ~2510 Bytes / sec Fixes: 96cb9d055445 ("hwrng: bcm2835 - use hwrng_msleep() instead of cpu_relax()") Link: https://lore.kernel.org/linux-arm-kernel/bc97ece5-44a3-4c4e-77da-2db3eb66b128@gmx.net/ Signed-off-by: Stefan Wahren Reviewed-by: Jason A. Donenfeld Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

hwrng: core - treat default_quality as a maximum and default to 1024

2022-11-18T08:59:34+00:00

Most hw_random devices return entropy which is assumed to be of full quality, but driver authors don't bother setting the quality knob. Some hw_random devices return less than full quality entropy, and then driver authors set the quality knob. Therefore, the entropy crediting should be opt-out rather than opt-in per-driver, to reflect the actual reality on the ground. For example, the two Raspberry Pi RNG drivers produce full entropy randomness, and both EDK2 and U-Boot's drivers for these treat them as such. The result is that EFI then uses these numbers and passes the to Linux, and Linux credits them as boot, thereby initializing the RNG. Yet, in Linux, the quality knob was never set to anything, and so on the chance that Linux is booted without EFI, nothing is ever credited. That's annoying. The same pattern appears to repeat itself throughout various drivers. In fact, very very few drivers have bothered setting quality=1024. Looking at the git history of existing drivers and corresponding mailing list discussion, this conclusion tracks. There's been a decent amount of discussion about drivers that set quality < 1024 -- somebody read and interepreted a datasheet, or made some back of the envelope calculation somehow. But there's been very little, if any, discussion about most drivers where the quality is just set to 1024 or unset (or set to 1000 when the authors misunderstood the API and assumed it was base-10 rather than base-2); in both cases the intent was fairly clear of, "this is a hardware random device; it's fine." So let's invert this logic. A hw_random struct's quality knob now controls the maximum quality a driver can produce, or 0 to specify 1024. Then, the module-wide switch called "default_quality" is changed to represent the maximum quality of any driver. By default it's 1024, and the quality of any particular driver is then given by: min(default_quality, rng->quality ?: 1024); This way, the user can still turn this off for weird reasons (and we can replace whatever driver-specific disabling hacks existed in the past), yet we get proper crediting for relevant RNGs. Cc: Dominik Brodowski Cc: Ard Biesheuvel Cc: Herbert Xu Signed-off-by: Jason A. Donenfeld Signed-off-by: Herbert Xu

hwrng: core - let sleep be interrupted when unregistering hwrng

2022-08-19T10:39:34+00:00

There are two deadlock scenarios that need addressing, which cause problems when the computer goes to sleep, the interface is set down, and hwrng_unregister() is called. When the deadlock is hit, sleep is delayed for tens of seconds, causing it to fail. These scenarios are: 1) The hwrng kthread can't be stopped while it's sleeping, because it uses msleep_interruptible() which does not react to kthread_stop. 2) A normal user thread can't be interrupted by hwrng_unregister() while it's sleeping, because hwrng_unregister() is called from elsewhere. We solve both issues by add a completion object called dying that fulfils waiters once we have started the process in hwrng_unregister. At the same time, we should cleanup a common and useless dmesg splat in the same area. Cc: Reported-by: Gregory Erwin Fixes: fcd09c90c3c5 ("ath9k: use hw_random API instead of directly dumping into random.c") Link: https://lore.kernel.org/all/CAO+Okf6ZJC5-nTE_EJUGQtd8JiCkiEHytGgDsFGTEjs0c00giw@mail.gmail.com/ Link: https://lore.kernel.org/lkml/CAO+Okf5k+C+SE6pMVfPf-d8MfVPVq4PO7EY8Hys_DVXtent3HA@mail.gmail.com/ Link: https://bugs.archlinux.org/task/75138 Signed-off-by: Jason A. Donenfeld Signed-off-by: Herbert Xu Acked-by: Toke Høiland-Jørgensen Acked-by: Kalle Valo Signed-off-by: Herbert Xu

random: pull add_hwgenerator_randomness() declaration into random.h

2022-02-21T20:14:21+00:00

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

random: make more consistent use of integer types

2022-02-21T20:13:54+00:00

We've been using a flurry of int, unsigned int, size_t, and ssize_t. Let's unify all of this into size_t where it makes sense, as it does in most places, and leave ssize_t for return values with possible errors. In addition, keeping with the convention of other functions in this file, functions that are dealing with raw bytes now take void * consistently instead of a mix of that and u8 *, because much of the time we're actually passing some other structure that is then interpreted as bytes by the function. We also take the opportunity to fix the outdated and incorrect comment in get_random_bytes_arch(). Cc: Theodore Ts'o Reviewed-by: Dominik Brodowski Reviewed-by: Jann Horn Reviewed-by: Eric Biggers Signed-off-by: Jason A. Donenfeld

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: Make explicit that max >= 32 always

2016-11-21T14:50:45+00:00

As hw_random core calls ->read with max > 32 or more, make it explicit. Also remove checks involving 'max' being less than 8. Signed-off-by: PrasannaKumar Muralidharan Signed-off-by: Herbert Xu

hwrng: core - Improve description of the ->read() interface

2016-08-24T13:04:48+00:00

Currently, very few RNG drivers support single byte reads using the ->read() interface. Of the 14 drivers in drivers/char/hw_random that support this interface only three of these actually support max == 1. The other behaviours vary between return 0, return 2, return 4 and return -EIO). This is not a problem in practice because the core hw_random code never performs a read shorter than 16 bytes. The documentation for this function already contrains the alignment of the buffer pointer, so let's also guarantee that the buffer is at least as large as its alignment. This constraint is intended to be the weakest guarantee neccessary to allow driver writers to safely simplify their code. Signed-off-by: Daniel Thompson Signed-off-by: Herbert Xu

hwrng: add devm_* interfaces

2015-03-16T10:45:54+00:00

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: Dmitry Torokhov Signed-off-by: Herbert Xu