| Message ID | 20220705190121.293703-1-Jason@zx2c4.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | random: remove CONFIG_ARCH_RANDOM and "nordrand" | expand |
On Tue, Jul 05, 2022 at 09:01:21PM +0200, Jason A. Donenfeld wrote: > @@ -26,7 +18,6 @@ __setup("nordrand", x86_rdrand_setup); > */ > #define SANITY_CHECK_LOOPS 8 > > -#ifdef CONFIG_ARCH_RANDOM > void x86_init_rdrand(struct cpuinfo_x86 *c) > { > unsigned int changed = 0; > @@ -59,8 +50,6 @@ void x86_init_rdrand(struct cpuinfo_x86 *c) > } > > if (WARN_ON_ONCE(!changed)) > - pr_emerg( > -"RDRAND gives funky smelling output, might consider not using it by booting with \"nordrand\""); > + pr_emerg("RDRAND gives funky smelling output; update microcode or firmware."); It is highly unlikely to get a BIOS or microcode update for that matter, for old systems: 7879fc4bdc75 ("x86/rdrand: Sanity-check RDRAND output") so I guess here you're better off saying that the kernel simply disables rdrand support and do clear_cpu_cap(c, X86_FEATURE_RDRAND); here too. If I read the commit message above correctly, it sounds like RDRAND output is not that important anyway... Thx.
Hey Borislav, On Tue, Jul 05, 2022 at 09:36:20PM +0200, Borislav Petkov wrote: > On Tue, Jul 05, 2022 at 09:01:21PM +0200, Jason A. Donenfeld wrote: > > @@ -26,7 +18,6 @@ __setup("nordrand", x86_rdrand_setup); > > */ > > #define SANITY_CHECK_LOOPS 8 > > > > -#ifdef CONFIG_ARCH_RANDOM > > void x86_init_rdrand(struct cpuinfo_x86 *c) > > { > > unsigned int changed = 0; > > @@ -59,8 +50,6 @@ void x86_init_rdrand(struct cpuinfo_x86 *c) > > } > > > > if (WARN_ON_ONCE(!changed)) > > - pr_emerg( > > -"RDRAND gives funky smelling output, might consider not using it by booting with \"nordrand\""); > > + pr_emerg("RDRAND gives funky smelling output; update microcode or firmware."); > > It is highly unlikely to get a BIOS or microcode update for that matter, > for old systems: > > 7879fc4bdc75 ("x86/rdrand: Sanity-check RDRAND output") > > so I guess here you're better off saying that the kernel simply disables > rdrand support and do > > clear_cpu_cap(c, X86_FEATURE_RDRAND); > > here too. Oh, huh. Maybe in that case I should adjust the message to say "consider using `random.trust_cpu=0`," which is the thing that would actually make a security difference. But actually, one thing that wasn't clear to me was: does `nordrand` affect what userspace sees? While random.c is okay in lots of circumstances, I could imagine `nordrand` playing a role in preventing userspace from using it, which might be desirable. Is this the case? If so, I can remove the nordrand chunk from this patch for v2. If not, I'll adjust the text to mention `random.trust_cpu=0`. > If I read the commit message above correctly, it sounds like RDRAND > output is not that important anyway... In the sense that random.c can handle mostly any input without making the quality worse. So, you can't accidentally taint it. The only risk is if it thinks RDRAND is good and trustable when it isn't, but that's what `random.trust_cpu=0` is for. Jason
On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote: > Oh, huh. Maybe in that case I should adjust the message to say "consider > using `random.trust_cpu=0`," which is the thing that would actually make > a security difference. Why isn't that option documented in Documentation/admin-guide/kernel-parameters.txt? > But actually, one thing that wasn't clear to me was: does `nordrand` > affect what userspace sees? While random.c is okay in lots of > circumstances, I could imagine `nordrand` playing a role in preventing > userspace from using it, which might be desirable. Is this the case? If > so, I can remove the nordrand chunk from this patch for v2. If not, I'll > adjust the text to mention `random.trust_cpu=0`. Unfortunately, it doesn't disable the instruction. It would be lovely if we had a switch like that... That's why this message is supposed to be noisy so that people can pay attention at least. > In the sense that random.c can handle mostly any input without making > the quality worse. So, you can't accidentally taint it. The only risk is > if it thinks RDRAND is good and trustable when it isn't, but that's what > `random.trust_cpu=0` is for. And that's why I'm saying that if you detect RDRAND returning the same thing over and over again, you should simply stop using it. Automatically. Not rely on the user to do anything.
On July 5, 2022 12:57:04 PM PDT, Borislav Petkov <bp@alien8.de> wrote: >On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote: >> Oh, huh. Maybe in that case I should adjust the message to say "consider >> using `random.trust_cpu=0`," which is the thing that would actually make >> a security difference. > >Why isn't that option documented in >Documentation/admin-guide/kernel-parameters.txt? > >> But actually, one thing that wasn't clear to me was: does `nordrand` >> affect what userspace sees? While random.c is okay in lots of >> circumstances, I could imagine `nordrand` playing a role in preventing >> userspace from using it, which might be desirable. Is this the case? If >> so, I can remove the nordrand chunk from this patch for v2. If not, I'll >> adjust the text to mention `random.trust_cpu=0`. > >Unfortunately, it doesn't disable the instruction. It would be lovely if >we had a switch like that... > >That's why this message is supposed to be noisy so that people can pay >attention at least. > >> In the sense that random.c can handle mostly any input without making >> the quality worse. So, you can't accidentally taint it. The only risk is >> if it thinks RDRAND is good and trustable when it isn't, but that's what >> `random.trust_cpu=0` is for. > >And that's why I'm saying that if you detect RDRAND returning the >same thing over and over again, you should simply stop using it. >Automatically. Not rely on the user to do anything. > It's just math. The only variable is your confidence level, i.e. at what level do you decide that the likelihood of pure chance is way smaller than the likelihood of hardware failure. For example, the likelihood of m n-bit samples in a row being identical is 2^-(n*(m-3/2)), and the likelihood of the CPU being destroyed by a meterorite in the same microsecond is about 2^-100.
On Tue, Jul 05, 2022 at 02:50:34PM -0700, H. Peter Anvin wrote: > It's just math. The only variable is your confidence level, i.e. at > what level do you decide that the likelihood of pure chance is way > smaller than the likelihood of hardware failure. That might be but the likelyhood of certain BIOSes dropping the ball after resume is 100%: 7879fc4bdc75 ("x86/rdrand: Sanity-check RDRAND output")
On July 5, 2022 3:00:04 PM PDT, Borislav Petkov <bp@alien8.de> wrote: >On Tue, Jul 05, 2022 at 02:50:34PM -0700, H. Peter Anvin wrote: >> It's just math. The only variable is your confidence level, i.e. at >> what level do you decide that the likelihood of pure chance is way >> smaller than the likelihood of hardware failure. > >That might be but the likelyhood of certain BIOSes dropping the ball >after resume is 100%: > >7879fc4bdc75 ("x86/rdrand: Sanity-check RDRAND output") > What I'm wondering is if we shouldn't be simply instrument *every* invocation, and set the trust to zero if we ever trip it.
Hi Borislav, Peter, On Tue, Jul 05, 2022 at 02:50:34PM -0700, H. Peter Anvin wrote: > On July 5, 2022 12:57:04 PM PDT, Borislav Petkov <bp@alien8.de> wrote: > >On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote: > >> Oh, huh. Maybe in that case I should adjust the message to say "consider > >> using `random.trust_cpu=0`," which is the thing that would actually make > >> a security difference. > > > >Why isn't that option documented in > >Documentation/admin-guide/kernel-parameters.txt? Maybe you're not grepping the right tree? zx2c4@thinkpad ~/Projects/random-linux $ grep trust_cpu Documentation/admin-guide/kernel-parameters.txt random.trust_cpu={on,off} https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/tree/Documentation/admin-guide/kernel-parameters.txt#n4506 > >> But actually, one thing that wasn't clear to me was: does `nordrand` > >> affect what userspace sees? While random.c is okay in lots of > >> circumstances, I could imagine `nordrand` playing a role in preventing > >> userspace from using it, which might be desirable. Is this the case? If > >> so, I can remove the nordrand chunk from this patch for v2. If not, I'll > >> adjust the text to mention `random.trust_cpu=0`. > > > >Unfortunately, it doesn't disable the instruction. It would be lovely if > >we had a switch like that... > > > >That's why this message is supposed to be noisy so that people can pay > >attention at least. I was wondering if it somehow removed it from cpuid. But I guess that's not possible. So okay, no real userspace effect. I think I agree with you then: > >> In the sense that random.c can handle mostly any input without making > >> the quality worse. So, you can't accidentally taint it. The only risk is > >> if it thinks RDRAND is good and trustable when it isn't, but that's what > >> `random.trust_cpu=0` is for. > > > >And that's why I'm saying that if you detect RDRAND returning the > >same thing over and over again, you should simply stop using it. > >Automatically. Not rely on the user to do anything. > > > > It's just math. The only variable is your confidence level, i.e. at > what level do you decide that the likelihood of pure chance is way > smaller than the likelihood of hardware failure. For example, the > likelihood of m n-bit samples in a row being identical is > 2^-(n*(m-3/2)), and the likelihood of the CPU being destroyed by a > meterorite in the same microsecond is about 2^-100. I think I'm on board with that general plan of adding a little online selftest that's better than what's there now and using that to get rid of nordrand. I don't want to instrument every invocation like you suggested, because this has effects on forward secrecy (e.g. it's nice to burn previous results from memory). But doing a little test at boot up better than what we have now seems like a good idea. So let's do this - I'll send a v2 changing this patch to be a bit more boring and just get rid of CONFIG_ARCH_RANDOM. That'll be straight forward. And then Peter - do you want to take a stab at doing the selftest in order to get rid of nordrand? Or would you prefer I try? It sounds like you have a specific idea of what you'd like there, so maybe that's best? For now, v2 of this patch sans nordrand is incoming shortly. Jason
On Tue, Jul 05, 2022 at 04:11:45PM -0700, H. Peter Anvin wrote: > What I'm wondering is if we shouldn't be simply instrument *every* > invocation, and set the trust to zero if we ever trip it. I guess you can add some logic to rdrand_long() to sanity-check what it returns... But would that be worth the effort?
On Wed, Jul 06, 2022 at 02:28:19AM +0200, Jason A. Donenfeld wrote: > Maybe you're not grepping the right tree? > > zx2c4@thinkpad ~/Projects/random-linux $ grep trust_cpu Documentation/admin-guide/kernel-parameters.txt > random.trust_cpu={on,off} I was looking at the wrong option, sorry about that.
On Tue, Jul 05, 2022 at 09:01:21PM +0200, Jason A. Donenfeld wrote: > Later the thinking evolved. With a properly designed RNG, using RDRAND > values alone won't harm anything, even if the outputs are malicious. I personally think it's totally fine to remove nordrand. However, the reason why it was there was that there were some rather extreme tin-foil-hatters who believed that if (the completely unavailable to the public for auditing) RDRAND implementation *were* malicious *and* the microcode had access to the register file and/or the instruction pipeline, then in theory, a malicious CPU could subvert how the RDRAND is mixed into the getrandom output to force a particular output. Personally, I've always considered it to be insane, since a much easier way to compromise a CPU would be to drop a Minix system hidden into the CPU running a web server that had massive security bugs in it that were only discovered years later. And if you don't trust the CPU manufacture to that extent, you should probably simply not use CPU's from that manufacturer. :-) - Ted
Hi Ted, On Wed, Jul 06, 2022 at 10:55:04AM -0400, Theodore Ts'o wrote: > On Tue, Jul 05, 2022 at 09:01:21PM +0200, Jason A. Donenfeld wrote: > > Later the thinking evolved. With a properly designed RNG, using RDRAND > > values alone won't harm anything, even if the outputs are malicious. > > I personally think it's totally fine to remove nordrand. However, the > reason why it was there was that there were some rather extreme > tin-foil-hatters who believed that if (the completely unavailable to > the public for auditing) RDRAND implementation *were* malicious *and* > the microcode had access to the register file and/or the instruction > pipeline, then in theory, a malicious CPU could subvert how the RDRAND > is mixed into the getrandom output to force a particular output. > > Personally, I've always considered it to be insane, since a much > easier way to compromise a CPU would be to drop a Minix system hidden > into the CPU running a web server that had massive security bugs in it > that were only discovered years later. And if you don't trust the CPU > manufacture to that extent, you should probably simply not use CPU's > from that manufacturer. :-) That specific attack scenario is actually something I've fixed over the last few months, by ensuring that all RDRAND values go through the hash function. So even if the CPU is super malicious, it'd still need a hash preimage, which isn't considered to be computable for blake2s. Minix in the cpu... haha.. surely that would never happen... haha surely... Jason
On July 6, 2022 5:23:31 AM PDT, Borislav Petkov <bp@alien8.de> wrote: >On Tue, Jul 05, 2022 at 04:11:45PM -0700, H. Peter Anvin wrote: >> What I'm wondering is if we shouldn't be simply instrument *every* >> invocation, and set the trust to zero if we ever trip it. > >I guess you can add some logic to rdrand_long() to sanity-check what it >returns... > >But would that be worth the effort? > I think doing it centrally, as non-arch-specific code, and letting it subsume ad hoc checks for known failure conditions could be a win.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 2522b11e593f..a1dc4dbf74f6 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3733,11 +3733,6 @@ noreplace-smp [X86-32,SMP] Don't replace SMP instructions with UP alternatives - nordrand [X86] Disable kernel use of the RDRAND and - RDSEED instructions even if they are supported - by the processor. RDRAND and RDSEED are still - available to user space applications. - noresume [SWSUSP] Disables resume and restores original swap space. 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 <linux/arm-smccc.h> #include <linux/bug.h> #include <linux/kernel.h> @@ -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 */ #endif /* _ASM_ARCHRANDOM_H */ diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index 8d88433de81d..0e9462abeb77 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -2416,7 +2416,6 @@ static const struct arm64_cpu_capabilities arm64_features[] = { .cpu_enable = cpu_enable_e0pd, }, #endif -#ifdef CONFIG_ARCH_RANDOM { .desc = "Random Number Generator", .capability = ARM64_HAS_RNG, @@ -2428,7 +2427,6 @@ static const struct arm64_cpu_capabilities arm64_features[] = { .sign = FTR_UNSIGNED, .min_field_value = 1, }, -#endif #ifdef CONFIG_ARM64_BTI { .desc = "Branch Target Identification", diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index c2ce2e60c8f0..0d5757c125c4 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -1248,9 +1248,6 @@ config PHYSICAL_START default "0x00000000" endif -config ARCH_RANDOM - def_bool n - config PPC_LIB_RHEAP bool diff --git a/arch/powerpc/include/asm/archrandom.h b/arch/powerpc/include/asm/archrandom.h index 9a53e29680f4..25ba65df6b1a 100644 --- a/arch/powerpc/include/asm/archrandom.h +++ b/arch/powerpc/include/asm/archrandom.h @@ -2,8 +2,6 @@ #ifndef _ASM_POWERPC_ARCHRANDOM_H #define _ASM_POWERPC_ARCHRANDOM_H -#ifdef CONFIG_ARCH_RANDOM - #include <asm/machdep.h> static inline bool __must_check arch_get_random_long(unsigned long *v) @@ -35,7 +33,6 @@ static inline bool __must_check arch_get_random_seed_int(unsigned int *v) return rc; } -#endif /* CONFIG_ARCH_RANDOM */ #ifdef CONFIG_PPC_POWERNV int powernv_hwrng_present(void); diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h index 358d171ae8e0..6c1002043367 100644 --- a/arch/powerpc/include/asm/machdep.h +++ b/arch/powerpc/include/asm/machdep.h @@ -200,9 +200,7 @@ struct machdep_calls { ssize_t (*cpu_release)(const char *, size_t); #endif -#ifdef CONFIG_ARCH_RANDOM int (*get_random_seed)(unsigned long *v); -#endif }; extern void e500_idle(void); diff --git a/arch/powerpc/platforms/microwatt/Kconfig b/arch/powerpc/platforms/microwatt/Kconfig index 5e320f49583a..6af443a1db99 100644 --- a/arch/powerpc/platforms/microwatt/Kconfig +++ b/arch/powerpc/platforms/microwatt/Kconfig @@ -6,7 +6,6 @@ config PPC_MICROWATT select PPC_ICS_NATIVE select PPC_ICP_NATIVE select PPC_UDBG_16550 - select ARCH_RANDOM help This option enables support for FPGA-based Microwatt implementations. diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig index 161dfe024085..e1a05c5a9004 100644 --- a/arch/powerpc/platforms/powernv/Kconfig +++ b/arch/powerpc/platforms/powernv/Kconfig @@ -12,7 +12,6 @@ config PPC_POWERNV select EPAPR_BOOT select PPC_INDIRECT_PIO select PPC_UDBG_16550 - select ARCH_RANDOM select CPU_FREQ select PPC_DOORBELL select MMU_NOTIFIER diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index f7fd91d153a4..f4a647c1f0b2 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -19,7 +19,6 @@ config PPC_PSERIES select PPC_UDBG_16550 select PPC_DOORBELL select HOTPLUG_CPU - select ARCH_RANDOM select FORCE_SMP select SWIOTLB default y diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 91c0b80a8bf0..28a958b900f1 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -508,21 +508,6 @@ config KEXEC_SIG verification for the corresponding kernel image type being loaded in order for this to work. -config ARCH_RANDOM - def_bool y - prompt "s390 architectural random number generation API" - help - Enable the s390 architectural random number generation API - to provide random data for all consumers within the Linux - kernel. - - When enabled the arch_random_* functions declared in linux/random.h - are implemented. The implementation is based on the s390 CPACF - instruction subfunction TRNG which provides a real true random - number generator. - - If unsure, say Y. - config KERNEL_NOBP def_bool n prompt "Enable modified branch prediction for the kernel by default" diff --git a/arch/s390/configs/zfcpdump_defconfig b/arch/s390/configs/zfcpdump_defconfig index a87fcc45e307..f4976f611b94 100644 --- a/arch/s390/configs/zfcpdump_defconfig +++ b/arch/s390/configs/zfcpdump_defconfig @@ -15,7 +15,6 @@ CONFIG_TUNE_ZEC12=y # CONFIG_COMPAT is not set CONFIG_NR_CPUS=2 CONFIG_HZ_100=y -# CONFIG_ARCH_RANDOM is not set # CONFIG_RELOCATABLE is not set # CONFIG_CHSC_SCH is not set # CONFIG_SCM_BUS is not set diff --git a/arch/s390/crypto/Makefile b/arch/s390/crypto/Makefile index c63abfeb6d17..1b1cc478fa94 100644 --- a/arch/s390/crypto/Makefile +++ b/arch/s390/crypto/Makefile @@ -15,7 +15,7 @@ obj-$(CONFIG_CRYPTO_CHACHA_S390) += chacha_s390.o obj-$(CONFIG_S390_PRNG) += prng.o obj-$(CONFIG_CRYPTO_GHASH_S390) += ghash_s390.o obj-$(CONFIG_CRYPTO_CRC32_S390) += crc32-vx_s390.o -obj-$(CONFIG_ARCH_RANDOM) += arch_random.o +obj-y += arch_random.o crc32-vx_s390-y := crc32-vx.o crc32le-vx.o crc32be-vx.o chacha_s390-y := chacha-glue.o chacha-s390.o diff --git a/arch/s390/include/asm/archrandom.h b/arch/s390/include/asm/archrandom.h index 5dc712fde3c7..27a3ff021b96 100644 --- a/arch/s390/include/asm/archrandom.h +++ b/arch/s390/include/asm/archrandom.h @@ -11,8 +11,6 @@ #ifndef _ASM_S390_ARCHRANDOM_H #define _ASM_S390_ARCHRANDOM_H -#ifdef CONFIG_ARCH_RANDOM - #include <linux/static_key.h> #include <linux/atomic.h> @@ -50,5 +48,4 @@ static inline bool __must_check arch_get_random_seed_int(unsigned int *v) return false; } -#endif /* CONFIG_ARCH_RANDOM */ #endif /* _ASM_S390_ARCHRANDOM_H */ diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index be0b95e51df6..59b82135c814 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1833,15 +1833,6 @@ config ARCH_USES_PG_UNCACHED def_bool y depends on X86_PAT -config ARCH_RANDOM - def_bool y - prompt "x86 architectural random number generator" if EXPERT - help - Enable the x86 architectural RDRAND instruction - (Intel Bull Mountain technology) to generate random numbers. - If supported, this is a high bandwidth, cryptographically - secure hardware random number generator. - config X86_UMIP def_bool y prompt "User Mode Instruction Prevention" if EXPERT diff --git a/arch/x86/include/asm/archrandom.h b/arch/x86/include/asm/archrandom.h index ebc248e49549..1d7bd74d2b44 100644 --- a/arch/x86/include/asm/archrandom.h +++ b/arch/x86/include/asm/archrandom.h @@ -65,10 +65,8 @@ static inline bool __must_check rdseed_int(unsigned int *v) /* * These are the generic interfaces; they must not be declared if the - * stubs in <linux/random.h> are to be invoked, - * i.e. CONFIG_ARCH_RANDOM is not defined. + * stubs in <linux/random.h> are to be invoked. */ -#ifdef CONFIG_ARCH_RANDOM static inline bool __must_check arch_get_random_long(unsigned long *v) { @@ -92,10 +90,4 @@ static inline bool __must_check arch_get_random_seed_int(unsigned int *v) extern void x86_init_rdrand(struct cpuinfo_x86 *c); -#else /* !CONFIG_ARCH_RANDOM */ - -static inline void x86_init_rdrand(struct cpuinfo_x86 *c) { } - -#endif /* !CONFIG_ARCH_RANDOM */ - #endif /* ASM_X86_ARCHRANDOM_H */ diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 0c0b09796ced..216fc2f53cbe 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -808,7 +808,7 @@ static void clear_rdrand_cpuid_bit(struct cpuinfo_x86 *c) return; /* - * The nordrand option can clear X86_FEATURE_RDRAND, so check for + * The self test can clear X86_FEATURE_RDRAND, so check for * RDRAND support using the CPUID function directly. */ if (!(cpuid_ecx(1) & BIT(30)) || rdrand_force) diff --git a/arch/x86/kernel/cpu/rdrand.c b/arch/x86/kernel/cpu/rdrand.c index c4be62058dd9..d66480b17f26 100644 --- a/arch/x86/kernel/cpu/rdrand.c +++ b/arch/x86/kernel/cpu/rdrand.c @@ -11,14 +11,6 @@ #include <asm/archrandom.h> #include <asm/sections.h> -static int __init x86_rdrand_setup(char *s) -{ - setup_clear_cpu_cap(X86_FEATURE_RDRAND); - setup_clear_cpu_cap(X86_FEATURE_RDSEED); - return 1; -} -__setup("nordrand", x86_rdrand_setup); - /* * RDRAND has Built-In-Self-Test (BIST) that runs on every invocation. * Run the instruction a few times as a sanity check. @@ -26,7 +18,6 @@ __setup("nordrand", x86_rdrand_setup); */ #define SANITY_CHECK_LOOPS 8 -#ifdef CONFIG_ARCH_RANDOM void x86_init_rdrand(struct cpuinfo_x86 *c) { unsigned int changed = 0; @@ -59,8 +50,6 @@ void x86_init_rdrand(struct cpuinfo_x86 *c) } if (WARN_ON_ONCE(!changed)) - pr_emerg( -"RDRAND gives funky smelling output, might consider not using it by booting with \"nordrand\""); + pr_emerg("RDRAND gives funky smelling output; update microcode or firmware."); } -#endif diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 0b6c03643ddc..30192e123e5f 100644 --- 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 diff --git a/drivers/char/hw_random/s390-trng.c b/drivers/char/hw_random/s390-trng.c index 2beaa35c0d74..488808dc17a2 100644 --- a/drivers/char/hw_random/s390-trng.c +++ b/drivers/char/hw_random/s390-trng.c @@ -108,7 +108,6 @@ static ssize_t trng_counter_show(struct device *dev, { u64 dev_counter = atomic64_read(&trng_dev_counter); u64 hwrng_counter = atomic64_read(&trng_hwrng_counter); -#if IS_ENABLED(CONFIG_ARCH_RANDOM) u64 arch_counter = atomic64_read(&s390_arch_random_counter); return sysfs_emit(buf, @@ -118,14 +117,6 @@ static ssize_t trng_counter_show(struct device *dev, "total: %llu\n", dev_counter, hwrng_counter, arch_counter, dev_counter + hwrng_counter + arch_counter); -#else - return sysfs_emit(buf, - "trng: %llu\n" - "hwrng: %llu\n" - "total: %llu\n", - dev_counter, hwrng_counter, - dev_counter + hwrng_counter); -#endif } static DEVICE_ATTR(byte_counter, 0444, trng_counter_show, NULL); diff --git a/include/linux/random.h b/include/linux/random.h index 20e389a14e5c..865770e29f3e 100644 --- a/include/linux/random.h +++ b/include/linux/random.h @@ -106,14 +106,7 @@ declare_get_random_var_wait(long, unsigned long) */ #include <linux/prandom.h> -#ifdef CONFIG_ARCH_RANDOM -# include <asm/archrandom.h> -#else -static inline bool __must_check arch_get_random_long(unsigned long *v) { return false; } -static inline bool __must_check arch_get_random_int(unsigned int *v) { return false; } -static inline bool __must_check arch_get_random_seed_long(unsigned long *v) { return false; } -static inline bool __must_check arch_get_random_seed_int(unsigned int *v) { return false; } -#endif +#include <asm/archrandom.h> /* * Called from the boot CPU during startup; not valid to call once diff --git a/tools/testing/selftests/wireguard/qemu/kernel.config b/tools/testing/selftests/wireguard/qemu/kernel.config index bad88f4b0a03..e1858ce7003f 100644 --- a/tools/testing/selftests/wireguard/qemu/kernel.config +++ b/tools/testing/selftests/wireguard/qemu/kernel.config @@ -58,7 +58,6 @@ CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ_FULL=n CONFIG_HZ_PERIODIC=n CONFIG_HIGH_RES_TIMERS=y -CONFIG_ARCH_RANDOM=y CONFIG_FILE_LOCKING=y CONFIG_POSIX_TIMERS=y CONFIG_DEVTMPFS=y
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. So this commit simplifies things down to the two options that are actually used, and removes the confusing old ones that aren't used or useful. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- Documentation/admin-guide/kernel-parameters.txt | 5 ----- 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 | 10 +--------- arch/x86/kernel/cpu/amd.c | 2 +- arch/x86/kernel/cpu/rdrand.c | 13 +------------ drivers/char/Kconfig | 1 - drivers/char/hw_random/s390-trng.c | 9 --------- include/linux/random.h | 9 +-------- .../selftests/wireguard/qemu/kernel.config | 1 - 22 files changed, 5 insertions(+), 106 deletions(-)