linux/drivers/char/hw_random/Kconfig

633 lines
19 KiB
Text
Raw Permalink Normal View History

# SPDX-License-Identifier: GPL-2.0-only
#
# Hardware Random Number Generator (RNG) configuration
#
menuconfig HW_RANDOM
tristate "Hardware Random Number Generator Core support"
default m
help
Hardware Random Number Generator Core infrastructure.
To compile this driver as a module, choose M here: the
module will be called rng-core. This provides a device
that's usually called /dev/hwrng, and which exposes one
of possibly several hardware random number generators.
These hardware random number generators do feed into the
kernel's random number generator entropy pool.
If unsure, say Y.
if HW_RANDOM
config HW_RANDOM_TIMERIOMEM
tristate "Timer IOMEM HW Random Number Generator support"
depends on HAS_IOMEM
help
This driver provides kernel-side support for a generic Random
Number Generator used by reading a 'dumb' iomem address that
is to be read no faster than, for example, once a second;
the default FPGA bitstream on the TS-7800 has such functionality.
To compile this driver as a module, choose M here: the
module will be called timeriomem-rng.
If unsure, say Y.
config HW_RANDOM_INTEL
tristate "Intel HW Random Number Generator support"
arch: Remove Itanium (IA-64) architecture The Itanium architecture is obsolete, and an informal survey [0] reveals that any residual use of Itanium hardware in production is mostly HP-UX or OpenVMS based. The use of Linux on Itanium appears to be limited to enthusiasts that occasionally boot a fresh Linux kernel to see whether things are still working as intended, and perhaps to churn out some distro packages that are rarely used in practice. None of the original companies behind Itanium still produce or support any hardware or software for the architecture, and it is listed as 'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers that contributed on behalf of those companies (nor anyone else, for that matter) have been willing to support or maintain the architecture upstream or even be responsible for applying the odd fix. The Intel firmware team removed all IA-64 support from the Tianocore/EDK2 reference implementation of EFI in 2018. (Itanium is the original architecture for which EFI was developed, and the way Linux supports it deviates significantly from other architectures.) Some distros, such as Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have dropped support years ago. While the argument is being made [1] that there is a 'for the common good' angle to being able to build and run existing projects such as the Grid Community Toolkit [2] on Itanium for interoperability testing, the fact remains that none of those projects are known to be deployed on Linux/ia64, and very few people actually have access to such a system in the first place. Even if there were ways imaginable in which Linux/ia64 could be put to good use today, what matters is whether anyone is actually doing that, and this does not appear to be the case. There are no emulators widely available, and so boot testing Itanium is generally infeasible for ordinary contributors. GCC still supports IA-64 but its compile farm [3] no longer has any IA-64 machines. GLIBC would like to get rid of IA-64 [4] too because it would permit some overdue code cleanups. In summary, the benefits to the ecosystem of having IA-64 be part of it are mostly theoretical, whereas the maintenance overhead of keeping it supported is real. So let's rip off the band aid, and remove the IA-64 arch code entirely. This follows the timeline proposed by the Debian/ia64 maintainer [5], which removes support in a controlled manner, leaving IA-64 in a known good state in the most recent LTS release. Other projects will follow once the kernel support is removed. [0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/ [1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/ [2] https://gridcf.org/gct-docs/latest/index.html [3] https://cfarm.tetaneutral.net/machines/list/ [4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/ [5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/ Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-10-20 15:54:33 +02:00
depends on (X86 || COMPILE_TEST) && PCI
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on Intel i8xx-based motherboards.
To compile this driver as a module, choose M here: the
module will be called intel-rng.
If unsure, say Y.
config HW_RANDOM_AMD
tristate "AMD HW Random Number Generator support"
depends on (X86 || COMPILE_TEST)
depends on PCI && HAS_IOPORT_MAP
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on AMD 76x-based motherboards.
To compile this driver as a module, choose M here: the
module will be called amd-rng.
If unsure, say Y.
config HW_RANDOM_AIROHA
tristate "Airoha True HW Random Number Generator support"
depends on ARCH_AIROHA || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the True Random Number
Generator hardware found on Airoha SoC.
To compile this driver as a module, choose M here: the
module will be called airoha-rng.
If unsure, say Y.
config HW_RANDOM_ATMEL
tristate "Atmel Random Number Generator support"
depends on (ARCH_AT91 || COMPILE_TEST)
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on Atmel AT91 devices.
To compile this driver as a module, choose M here: the
module will be called atmel-rng.
If unsure, say Y.
config HW_RANDOM_BA431
tristate "Silex Insight BA431 Random Number Generator support"
depends on HAS_IOMEM
help
This driver provides kernel-side support for the Random Number
Generator hardware based on Silex Insight BA431 IP.
To compile this driver as a module, choose M here: the
module will be called ba431-rng.
config HW_RANDOM_BCM2835
tristate "Broadcom BCM2835/BCM63xx Random Number Generator support"
depends on ARCH_BCM2835 || ARCH_BCM_NSP || ARCH_BCM_5301X || \
ARCH_BCMBCA || BCM63XX || BMIPS_GENERIC || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on the Broadcom BCM2835 and BCM63xx SoCs.
To compile this driver as a module, choose M here: the
module will be called bcm2835-rng
If unsure, say Y.
config HW_RANDOM_BCM74110
tristate "Broadcom BCM74110 Random Number Generator support"
depends on ARCH_BRCMSTB || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on the Broadcom BCM74110 SoCs.
To compile this driver as a module, choose M here: the
module will be called bcm74110-rng
If unsure, say Y.
config HW_RANDOM_IPROC_RNG200
tristate "Broadcom iProc/STB RNG200 support"
depends on ARCH_BCM_IPROC || ARCH_BCM2835 || ARCH_BCMBCA || ARCH_BRCMSTB || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the RNG200
hardware found on the Broadcom iProc and STB SoCs.
To compile this driver as a module, choose M here: the
module will be called iproc-rng200
If unsure, say Y.
config HW_RANDOM_GEODE
tristate "AMD Geode HW Random Number Generator support"
depends on (X86_32 || COMPILE_TEST)
depends on PCI
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on the AMD Geode LX.
To compile this driver as a module, choose M here: the
module will be called geode-rng.
If unsure, say Y.
config HW_RANDOM_N2RNG
tristate "Niagara2 Random Number Generator support"
depends on SPARC64
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on Niagara2 cpus.
To compile this driver as a module, choose M here: the
module will be called n2-rng.
If unsure, say Y.
config HW_RANDOM_VIA
tristate "VIA HW Random Number Generator support"
depends on X86
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on VIA based motherboards.
To compile this driver as a module, choose M here: the
module will be called via-rng.
If unsure, say Y.
config HW_RANDOM_IXP4XX
tristate "Intel IXP4xx NPU HW Pseudo-Random Number Generator support"
depends on ARCH_IXP4XX || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Pseudo-Random
Number Generator hardware found on the Intel IXP45x/46x NPU.
To compile this driver as a module, choose M here: the
module will be called ixp4xx-rng.
If unsure, say Y.
config HW_RANDOM_OMAP
tristate "OMAP Random Number Generator support"
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS || ARCH_MVEBU || ARCH_K3 || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on OMAP16xx, OMAP2/3/4/5, AM33xx/AM43xx
multimedia processors, and Marvell Armada 7k/8k SoCs.
To compile this driver as a module, choose M here: the
module will be called omap-rng.
If unsure, say Y.
config HW_RANDOM_OMAP3_ROM
tristate "OMAP3 ROM Random Number Generator support"
depends on ARCH_OMAP3 || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on OMAP34xx processors.
To compile this driver as a module, choose M here: the
module will be called omap3-rom-rng.
If unsure, say Y.
config HW_RANDOM_OCTEON
tristate "Octeon Random Number Generator support"
depends on CAVIUM_OCTEON_SOC
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on Octeon processors.
To compile this driver as a module, choose M here: the
module will be called octeon-rng.
If unsure, say Y.
config HW_RANDOM_PASEMI
tristate "PA Semi HW Random Number Generator support"
depends on PPC_PASEMI || (PPC && COMPILE_TEST)
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on PA Semi PWRficient SoCs.
To compile this driver as a module, choose M here: the
module will be called pasemi-rng.
If unsure, say Y.
config HW_RANDOM_VIRTIO
tristate "VirtIO Random Number Generator support"
depends on VIRTIO
help
This driver provides kernel-side support for the virtual Random Number
Generator hardware.
To compile this driver as a module, choose M here: the
module will be called virtio-rng. If unsure, say N.
config HW_RANDOM_MXC_RNGA
tristate "Freescale i.MX RNGA Random Number Generator"
depends on SOC_IMX31 || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on Freescale i.MX processors.
To compile this driver as a module, choose M here: the
module will be called mxc-rnga.
If unsure, say Y.
config HW_RANDOM_IMX_RNGC
tristate "Freescale i.MX RNGC Random Number Generator"
depends on HAS_IOMEM
depends on SOC_IMX25 || SOC_IMX6SL || SOC_IMX6SLL || SOC_IMX6UL || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator Version C hardware found on some Freescale i.MX
processors. Version B is also supported by this driver.
To compile this driver as a module, choose M here: the
module will be called imx-rngc.
If unsure, say Y.
config HW_RANDOM_INGENIC_RNG
tristate "Ingenic Random Number Generator support"
depends on MACH_JZ4780 || MACH_X1000 || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number Generator
hardware found in ingenic JZ4780 and X1000 SoC. MIPS Creator CI20 uses
JZ4780 SoC, YSH & ATIL CU1000-Neo uses X1000 SoC.
To compile this driver as a module, choose M here: the
module will be called ingenic-rng.
If unsure, say Y.
config HW_RANDOM_INGENIC_TRNG
tristate "Ingenic True Random Number Generator support"
depends on MACH_X1830 || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the True Random Number Generator
hardware found in ingenic X1830 SoC. YSH & ATIL CU1830-Neo uses X1830 SoC.
To compile this driver as a module, choose M here: the
module will be called ingenic-trng.
If unsure, say Y.
config HW_RANDOM_NOMADIK
tristate "ST-Ericsson Nomadik Random Number Generator support"
depends on ARCH_NOMADIK || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on ST-Ericsson SoCs (8815 and 8500).
To compile this driver as a module, choose M here: the
module will be called nomadik-rng.
If unsure, say Y.
config HW_RANDOM_PSERIES
tristate "pSeries HW Random Number Generator support"
depends on PPC64 && IBMVIO
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on POWER7+ machines and above
To compile this driver as a module, choose M here: the
module will be called pseries-rng.
If unsure, say Y.
config HW_RANDOM_POWERNV
tristate "PowerNV Random Number Generator support"
depends on PPC_POWERNV
default HW_RANDOM
help
This is the driver for Random Number Generator hardware found
in POWER7+ and above machines for PowerNV platform.
To compile this driver as a module, choose M here: the
module will be called powernv-rng.
If unsure, say Y.
config HW_RANDOM_HISI
tristate "Hisilicon Random Number Generator support"
depends on ARCH_HISI || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on Hisilicon Hip04 and Hip05 SoC.
To compile this driver as a module, choose M here: the
module will be called hisi-rng.
If unsure, say Y.
config HW_RANDOM_HISTB
tristate "Hisilicon STB Random Number Generator support"
depends on ARCH_HISI || COMPILE_TEST
default ARCH_HISI
help
This driver provides kernel-side support for the Random Number
Generator hardware found on Hisilicon Hi37xx SoC.
To compile this driver as a module, choose M here: the
module will be called histb-rng.
config HW_RANDOM_ST
tristate "ST Microelectronics HW Random Number Generator support"
depends on ARCH_STI || COMPILE_TEST
help
This driver provides kernel-side support for the Random Number
Generator hardware found on STi series of SoCs.
To compile this driver as a module, choose M here: the
module will be called st-rng.
config HW_RANDOM_XGENE
tristate "APM X-Gene True Random Number Generator (TRNG) support"
depends on ARCH_XGENE || COMPILE_TEST
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on APM X-Gene SoC.
To compile this driver as a module, choose M here: the
module will be called xgene_rng.
If unsure, say Y.
config HW_RANDOM_STM32
tristate "STMicroelectronics STM32 random number generator"
depends on ARCH_STM32 || COMPILE_TEST
depends on HAS_IOMEM
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on STM32 microcontrollers.
To compile this driver as a module, choose M here: the
module will be called stm32-rng.
If unsure, say N.
config HW_RANDOM_PIC32
tristate "Microchip PIC32 Random Number Generator support"
depends on MACH_PIC32 || COMPILE_TEST
default HW_RANDOM if MACH_PIC32
help
This driver provides kernel-side support for the Random Number
Generator hardware found on a PIC32.
To compile this driver as a module, choose M here. the
module will be called pic32-rng.
If unsure, say Y.
config HW_RANDOM_POLARFIRE_SOC
tristate "Microchip PolarFire SoC Random Number Generator support"
depends on HW_RANDOM && POLARFIRE_SOC_SYS_CTRL
help
This driver provides kernel-side support for the Random Number
Generator hardware found on PolarFire SoC (MPFS).
To compile this driver as a module, choose M here. The
module will be called mfps_rng.
If unsure, say N.
config HW_RANDOM_MESON
tristate "Amlogic Meson Random Number Generator support"
depends on ARCH_MESON || COMPILE_TEST
depends on HAS_IOMEM && OF
default HW_RANDOM if ARCH_MESON
help
This driver provides kernel-side support for the Random Number
Generator hardware found on Amlogic Meson SoCs.
To compile this driver as a module, choose M here. the
module will be called meson-rng.
If unsure, say Y.
config HW_RANDOM_CAVIUM
tristate "Cavium ThunderX Random Number Generator support"
depends on PCI
depends on ARCH_THUNDER || (ARM64 && COMPILE_TEST)
default HW_RANDOM
help
This driver provides kernel-side support for the Random Number
Generator hardware found on Cavium SoCs.
To compile this driver as a module, choose M here: the
module will be called cavium_rng.
If unsure, say Y.
config HW_RANDOM_MTK
tristate "Mediatek Random Number Generator support"
depends on ARCH_MEDIATEK || COMPILE_TEST
depends on HAS_IOMEM && OF
default HW_RANDOM if ARCH_MEDIATEK
help
This driver provides kernel-side support for the Random Number
Generator hardware found on Mediatek SoCs.
To compile this driver as a module, choose M here. the
module will be called mtk-rng.
If unsure, say Y.
config HW_RANDOM_S390
tristate "S390 True Random Number Generator support"
depends on S390
default HW_RANDOM
help
This driver provides kernel-side support for the True
Random Number Generator available as CPACF extension
on modern s390 hardware platforms.
To compile this driver as a module, choose M here: the
module will be called s390-trng.
If unsure, say Y.
config HW_RANDOM_EXYNOS
tristate "Samsung Exynos True Random Number Generator support"
depends on ARCH_EXYNOS || COMPILE_TEST
depends on HAS_IOMEM
default HW_RANDOM if ARCH_EXYNOS
help
This driver provides support for the True Random Number
Generator available in Exynos SoCs.
To compile this driver as a module, choose M here: the module
will be called exynos-trng.
If unsure, say Y.
config HW_RANDOM_OPTEE
tristate "OP-TEE based Random Number Generator support"
depends on OPTEE
default HW_RANDOM
help
This driver provides support for OP-TEE based Random Number
Generator on ARM SoCs where hardware entropy sources are not
accessible to normal world (Linux).
To compile this driver as a module, choose M here: the module
will be called optee-rng.
If unsure, say Y.
config HW_RANDOM_NPCM
tristate "NPCM Random Number Generator support"
depends on ARCH_NPCM || COMPILE_TEST
depends on HAS_IOMEM
default HW_RANDOM if ARCH_NPCM
help
This driver provides support for the Random Number
Generator hardware available in Nuvoton NPCM SoCs.
To compile this driver as a module, choose M here: the
module will be called npcm-rng.
If unsure, say Y.
config HW_RANDOM_KEYSTONE
tristate "TI Keystone NETCP SA Hardware random number generator"
depends on ARCH_KEYSTONE || COMPILE_TEST
depends on HAS_IOMEM && OF
default HW_RANDOM
help
This option enables Keystone's hardware random generator.
config HW_RANDOM_CCTRNG
tristate "Arm CryptoCell True Random Number Generator support"
depends on HAS_IOMEM && OF
help
Say 'Y' to enable the True Random Number Generator driver for the
Arm TrustZone CryptoCell family of processors.
Currently the CryptoCell 713 and 703 are supported.
The driver is supported only in SoC where Trusted Execution
Environment is not used.
Choose 'M' to compile this driver as a module. The module
will be called cctrng.
If unsure, say 'N'.
config HW_RANDOM_XIPHERA
tristate "Xiphera FPGA based True Random Number Generator support"
depends on HAS_IOMEM
help
This driver provides kernel-side support for Xiphera True Random
Number Generator Intellectual Property Core.
To compile this driver as a module, choose M here: the
module will be called xiphera-trng.
config HW_RANDOM_ARM_SMCCC_TRNG
tristate "Arm SMCCC TRNG firmware interface support"
depends on HAVE_ARM_SMCCC_DISCOVERY
default HW_RANDOM
help
Say 'Y' to enable the True Random Number Generator driver using
the Arm SMCCC TRNG firmware interface. This reads entropy from
higher exception levels (firmware, hypervisor). Uses SMCCC for
communicating with the firmware:
https://developer.arm.com/documentation/den0098/latest/
To compile this driver as a module, choose M here: the
module will be called arm_smccc_trng.
config HW_RANDOM_CN10K
tristate "Marvell CN10K Random Number Generator support"
depends on HW_RANDOM && PCI && (ARM64 || (64BIT && COMPILE_TEST))
default HW_RANDOM if ARCH_THUNDER
help
This driver provides support for the True Random Number
generator available in Marvell CN10K SoCs.
To compile this driver as a module, choose M here.
The module will be called cn10k_rng. If unsure, say Y.
config HW_RANDOM_JH7110
tristate "StarFive JH7110 Random Number Generator support"
depends on SOC_STARFIVE || COMPILE_TEST
help
This driver provides support for the True Random Number
Generator in StarFive JH7110 SoCs.
To compile this driver as a module, choose M here.
The module will be called jh7110-trng.
config HW_RANDOM_ROCKCHIP
tristate "Rockchip True Random Number Generator"
depends on HW_RANDOM && (ARCH_ROCKCHIP || COMPILE_TEST)
depends on HAS_IOMEM
default HW_RANDOM
help
This driver provides kernel-side support for the True Random Number
hwrng: rockchip - add support for rk3588's standalone TRNG The RK3588 SoC includes several TRNGs, one part of the Crypto IP block, and the other one (referred to as "trngv1") as a standalone new IP. Add support for this new standalone TRNG to the driver by both generalising it to support multiple different rockchip RNGs and then implementing the required functionality for the new hardware. This work was partly based on the downstream vendor driver by Rockchip's Lin Jinhan, which is why they are listed as a Co-author. While the hardware does support notifying the CPU with an IRQ when the random data is ready, I've discovered while implementing the code to use this interrupt that this results in significantly slower throughput of the TRNG even when under heavy CPU load. I assume this is because with only 32 bytes of data per invocation, the overhead of reinitialising a completion, enabling the interrupt, sleeping and then triggering the completion in the IRQ handler is way more expensive than busylooping. Speaking of busylooping, the poll interval for reading the ISTAT is an atomic read with a delay of 0. In my testing, I've found that this gives us the largest throughput, and it appears the random data is ready pretty much the moment we begin polling, as increasing the poll delay leads to a drop in throughput significant enough to not just be due to the poll interval missing the ideal timing by a microsecond or two. According to downstream, the IP should take 1024 clock cycles to generate 56 bits of random data, which at 150MHz should work out to 6.8us. I did not test whether the data really does take 256/56*6.8us to arrive, though changing the readl to a __raw_readl makes no difference in throughput, and this data does pass the rngtest FIPS checks, so I'm not entirely sure what's going on but I presume it's got something to do with the AHB bus speed and the memory barriers that mainline's readl/writel functions insert. The only other current SoC that uses this new IP is the Rockchip RV1106, but that SoC does not have mainline support as of the time of writing, so we make no effort to declare it as supported for now. Co-developed-by: Lin Jinhan <troy.lin@rock-chips.com> Signed-off-by: Lin Jinhan <troy.lin@rock-chips.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2025-02-04 16:35:50 +01:00
Generator hardware found on some Rockchip SoCs like RK3566, RK3568
or RK3588.
To compile this driver as a module, choose M here: the
module will be called rockchip-rng.
If unsure, say Y.
endif # HW_RANDOM
config UML_RANDOM
depends on UML
um: random: Register random as hwrng-core device The UML random driver creates a dummy device under the guest, /dev/hw_random. When this file is read from the guest, the driver reads from the host machine's /dev/random, in-turn reading from the host kernel's entropy pool. This entropy pool could have been filled by a hardware random number generator or just the host kernel's internal software entropy generator. Currently the driver does not fill the guests kernel entropy pool, this requires a userspace tool running inside the guest (like rng-tools) to read from the dummy device provided by this driver, which then would fill the guest's internal entropy pool. This all seems quite pointless when we are already reading from an entropy pool, so this patch aims to register the device as a hwrng device using the hwrng-core framework. This not only improves and cleans up the driver, but also fills the guest's entropy pool without having to resort to using extra userspace tools in the guest. This is typically a nuisance when booting a guest: the random pool takes a long time (~200s) to build up enough entropy since the dummy hwrng is not used to fill the guest's pool. This port was originally attempted by Alexander Neville "dark" (in CC, discussion in Link), but the conversation there stalled since the handling of -EAGAIN errors were no removed and longer handled by the driver. This patch attempts to use the existing method of error handling but utilises the new hwrng core. The issue can be noticed when booting a UML guest: [ 2.560000] random: fast init done [ 214.000000] random: crng init done With the patch applied, filling the pool becomes a lot quicker: [ 2.560000] random: fast init done [ 12.000000] random: crng init done Cc: Alexander Neville <dark@volatile.bz> Link: https://lore.kernel.org/lkml/20190828204609.02a7ff70@TheDarkness/ Link: https://lore.kernel.org/lkml/20190829135001.6a5ff940@TheDarkness.local/ Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: Christopher Obbard <chris.obbard@collabora.com> Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-10-27 15:30:22 +00:00
select HW_RANDOM
tristate "UML Random Number Generator support"
help
This option enables UML's "hardware" random number generator. It
attaches itself to the host's /dev/random, supplying as much entropy
as the host has, rather than the small amount the UML gets from its
um: random: Register random as hwrng-core device The UML random driver creates a dummy device under the guest, /dev/hw_random. When this file is read from the guest, the driver reads from the host machine's /dev/random, in-turn reading from the host kernel's entropy pool. This entropy pool could have been filled by a hardware random number generator or just the host kernel's internal software entropy generator. Currently the driver does not fill the guests kernel entropy pool, this requires a userspace tool running inside the guest (like rng-tools) to read from the dummy device provided by this driver, which then would fill the guest's internal entropy pool. This all seems quite pointless when we are already reading from an entropy pool, so this patch aims to register the device as a hwrng device using the hwrng-core framework. This not only improves and cleans up the driver, but also fills the guest's entropy pool without having to resort to using extra userspace tools in the guest. This is typically a nuisance when booting a guest: the random pool takes a long time (~200s) to build up enough entropy since the dummy hwrng is not used to fill the guest's pool. This port was originally attempted by Alexander Neville "dark" (in CC, discussion in Link), but the conversation there stalled since the handling of -EAGAIN errors were no removed and longer handled by the driver. This patch attempts to use the existing method of error handling but utilises the new hwrng core. The issue can be noticed when booting a UML guest: [ 2.560000] random: fast init done [ 214.000000] random: crng init done With the patch applied, filling the pool becomes a lot quicker: [ 2.560000] random: fast init done [ 12.000000] random: crng init done Cc: Alexander Neville <dark@volatile.bz> Link: https://lore.kernel.org/lkml/20190828204609.02a7ff70@TheDarkness/ Link: https://lore.kernel.org/lkml/20190829135001.6a5ff940@TheDarkness.local/ Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk> Signed-off-by: Christopher Obbard <chris.obbard@collabora.com> Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2020-10-27 15:30:22 +00:00
own drivers. It registers itself as a rng-core driver thus providing
a device which is usually called /dev/hwrng. This hardware random
number generator does feed into the kernel's random number generator
entropy pool.
If unsure, say Y.