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 <catalin.marinas@xxxxxxx> > Cc: Will Deacon <will@xxxxxxxxxx> > Cc: Michael Ellerman <mpe@xxxxxxxxxxxxxx> > Cc: Alexander Gordeev <agordeev@xxxxxxxxxxxxx> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Cc: H. Peter Anvin <hpa@xxxxxxxxx> > Acked-by: Borislav Petkov <bp@xxxxxxx> > Acked-by: Heiko Carstens <hca@xxxxxxxxxxxxx> > Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx> For arm64: Acked-by: Catalin Marinas <catalin.marinas@xxxxxxx>
