Re: [PATCH v5] random: remove CONFIG_ARCH_RANDOM
Hi Jason,
On Fri, Jul 8, 2022 at 2:44 AM Jason A. Donenfeld wrote:
> When RDRAND was introduced, there was much discussion on whether it
> should be trusted and how the kernel should handle that. Initially, two
> mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
> "nordrand", a boot-time switch.
>
> Later the thinking evolved. With a properly designed RNG, using RDRAND
> values alone won't harm anything, even if the outputs are malicious.
> Rather, the issue is whether those values are being *trusted* to be good
> or not. And so a new set of options were introduced as the real
> ones that people use -- CONFIG_RANDOM_TRUST_CPU and "random.trust_cpu".
> With these options, RDRAND is used, but it's not always credited. So in
> the worst case, it does nothing, and in the best case, maybe it helps.
>
> Along the way, CONFIG_ARCH_RANDOM's meaning got sort of pulled into the
> center and became something certain platforms force-select.
>
> The old options don't really help with much, and it's a bit odd to have
> special handling for these instructions when the kernel can deal fine
> with the existence or untrusted existence or broken existence or
> non-existence of that CPU capability.
>
> Simplify the situation by removing CONFIG_ARCH_RANDOM and using the
> ordinary asm-generic fallback pattern instead, keeping the two options
> that are actually used. For now it leaves "nordrand" for now, as the
> removal of that will take a different route.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Michael Ellerman
> Cc: Alexander Gordeev
> Cc: Thomas Gleixner
> Cc: H. Peter Anvin
> Acked-by: Borislav Petkov
> Acked-by: Heiko Carstens
> Acked-by: Greg Kroah-Hartman
> Signed-off-by: Jason A. Donenfeld
Thanks for your patch, which is now commit 9592eef7c16ec5fb ("random:
remove CONFIG_ARCH_RANDOM") upstream.
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -431,7 +431,6 @@ config ADI
> config RANDOM_TRUST_CPU
> bool "Initialize RNG using CPU RNG instructions"
> default y
> - depends on ARCH_RANDOM
> help
> Initialize the RNG using random numbers supplied by the CPU's
> RNG instructions (e.g. RDRAND), if supported and available. These
This change means everyone configuring a kernel will be asked this
question, even when configuring for an architecture that does not
support RNG instructions.
Perhaps this question should be hidden behind EXPERT?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v5] random: remove CONFIG_ARCH_RANDOM
"Jason A. Donenfeld" writes: > When RDRAND was introduced, there was much discussion on whether it > should be trusted and how the kernel should handle that. Initially, two > mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and > "nordrand", a boot-time switch. ... > > arch/arm/include/asm/archrandom.h | 2 ++ > arch/arm64/Kconfig| 8 -- > arch/arm64/include/asm/archrandom.h | 10 > arch/arm64/kernel/cpufeature.c| 2 -- > arch/powerpc/Kconfig | 3 --- > arch/powerpc/include/asm/archrandom.h | 3 --- > arch/powerpc/include/asm/machdep.h| 2 -- > arch/powerpc/platforms/microwatt/Kconfig | 1 - > arch/powerpc/platforms/powernv/Kconfig| 1 - > arch/powerpc/platforms/pseries/Kconfig| 1 - Acked-by: Michael Ellerman (powerpc) cheers
Re: [PATCH v5] random: remove CONFIG_ARCH_RANDOM
On Fri, Jul 08, 2022 at 02:40:32AM +0200, Jason A. Donenfeld wrote: > When RDRAND was introduced, there was much discussion on whether it > should be trusted and how the kernel should handle that. Initially, two > mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and > "nordrand", a boot-time switch. > > Later the thinking evolved. With a properly designed RNG, using RDRAND > values alone won't harm anything, even if the outputs are malicious. > Rather, the issue is whether those values are being *trusted* to be good > or not. And so a new set of options were introduced as the real > ones that people use -- CONFIG_RANDOM_TRUST_CPU and "random.trust_cpu". > With these options, RDRAND is used, but it's not always credited. So in > the worst case, it does nothing, and in the best case, maybe it helps. > > Along the way, CONFIG_ARCH_RANDOM's meaning got sort of pulled into the > center and became something certain platforms force-select. > > The old options don't really help with much, and it's a bit odd to have > special handling for these instructions when the kernel can deal fine > with the existence or untrusted existence or broken existence or > non-existence of that CPU capability. > > Simplify the situation by removing CONFIG_ARCH_RANDOM and using the > ordinary asm-generic fallback pattern instead, keeping the two options > that are actually used. For now it leaves "nordrand" for now, as the > removal of that will take a different route. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Michael Ellerman > Cc: Alexander Gordeev > Cc: Thomas Gleixner > Cc: H. Peter Anvin > Acked-by: Borislav Petkov > Acked-by: Heiko Carstens > Acked-by: Greg Kroah-Hartman > Signed-off-by: Jason A. Donenfeld For arm64: Acked-by: Catalin Marinas
[PATCH v5] random: remove CONFIG_ARCH_RANDOM
When RDRAND was introduced, there was much discussion on whether it
should be trusted and how the kernel should handle that. Initially, two
mechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and
"nordrand", a boot-time switch.
Later the thinking evolved. With a properly designed RNG, using RDRAND
values alone won't harm anything, even if the outputs are malicious.
Rather, the issue is whether those values are being *trusted* to be good
or not. And so a new set of options were introduced as the real
ones that people use -- CONFIG_RANDOM_TRUST_CPU and "random.trust_cpu".
With these options, RDRAND is used, but it's not always credited. So in
the worst case, it does nothing, and in the best case, maybe it helps.
Along the way, CONFIG_ARCH_RANDOM's meaning got sort of pulled into the
center and became something certain platforms force-select.
The old options don't really help with much, and it's a bit odd to have
special handling for these instructions when the kernel can deal fine
with the existence or untrusted existence or broken existence or
non-existence of that CPU capability.
Simplify the situation by removing CONFIG_ARCH_RANDOM and using the
ordinary asm-generic fallback pattern instead, keeping the two options
that are actually used. For now it leaves "nordrand" for now, as the
removal of that will take a different route.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Michael Ellerman
Cc: Alexander Gordeev
Cc: Thomas Gleixner
Cc: H. Peter Anvin
Acked-by: Borislav Petkov
Acked-by: Heiko Carstens
Acked-by: Greg Kroah-Hartman
Signed-off-by: Jason A. Donenfeld
---
Changes v4->v5:
- Squelch warning on ARCH=um.
- Include asm-generic on arm instead of duplicating code.
Changes v3->v4:
- Use asm-generic for fallback.
Changes v2->v3:
- Keep compiling on archs with no ARCH_RANDOM.
Changes v1->v2:
- Get rid of nordrand change for now.
arch/arm/include/asm/archrandom.h | 2 ++
arch/arm64/Kconfig| 8 --
arch/arm64/include/asm/archrandom.h | 10
arch/arm64/kernel/cpufeature.c| 2 --
arch/powerpc/Kconfig | 3 ---
arch/powerpc/include/asm/archrandom.h | 3 ---
arch/powerpc/include/asm/machdep.h| 2 --
arch/powerpc/platforms/microwatt/Kconfig | 1 -
arch/powerpc/platforms/powernv/Kconfig| 1 -
arch/powerpc/platforms/pseries/Kconfig| 1 -
arch/s390/Kconfig | 15 ---
arch/s390/configs/zfcpdump_defconfig | 1 -
arch/s390/crypto/Makefile | 2 +-
arch/s390/include/asm/archrandom.h| 3 ---
arch/x86/Kconfig | 9 ---
arch/x86/include/asm/archrandom.h | 14 +++
arch/x86/kernel/cpu/rdrand.c | 2 --
drivers/char/Kconfig | 1 -
drivers/char/hw_random/s390-trng.c| 9 ---
include/asm-generic/Kbuild| 1 +
include/asm-generic/archrandom.h | 25 +++
include/linux/random.h| 9 +--
.../selftests/wireguard/qemu/kernel.config| 1 -
23 files changed, 34 insertions(+), 91 deletions(-)
create mode 100644 include/asm-generic/archrandom.h
diff --git a/arch/arm/include/asm/archrandom.h
b/arch/arm/include/asm/archrandom.h
index a8e84ca5c2ee..cc4714eb1a75 100644
--- a/arch/arm/include/asm/archrandom.h
+++ b/arch/arm/include/asm/archrandom.h
@@ -7,4 +7,6 @@ static inline bool __init smccc_probe_trng(void)
return false;
}
+#include
+
#endif /* _ASM_ARCHRANDOM_H */
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1652a9800ebe..1880f71c2547 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1858,14 +1858,6 @@ config ARM64_E0PD
This option enables E0PD for TTBR1 where available.
-config ARCH_RANDOM
- bool "Enable support for random number generation"
- default y
- help
- Random number generation (part of the ARMv8.5 Extensions)
- provides a high bandwidth, cryptographically secure
- hardware random number generator.
-
config ARM64_AS_HAS_MTE
# Initial support for MTE went in binutils 2.32.0, checked with
# ".arch armv8.5-a+memtag" below. However, this was incomplete
diff --git a/arch/arm64/include/asm/archrandom.h
b/arch/arm64/include/asm/archrandom.h
index 3a6b6d38c5b8..c3b9fa56af67 100644
--- a/arch/arm64/include/asm/archrandom.h
+++ b/arch/arm64/include/asm/archrandom.h
@@ -2,8 +2,6 @@
#ifndef _ASM_ARCHRANDOM_H
#define _ASM_ARCHRANDOM_H
-#ifdef CONFIG_ARCH_RANDOM
-
#include
#include
#include
@@ -167,12 +165,4 @@ arch_get_random_seed_long_early(unsigned long *v)
}
#define arch_get_random_seed_long_early arch_get_random_seed_long_early
-#else /* !CONFIG_ARCH_RANDOM */
-
-static inline bool __init smccc_probe_trng(void)
-{
- return false;
-}
-
-#endif /* CONFIG_ARCH_RANDOM *
