diff options
Diffstat (limited to '0045-random-credit-cpu-and-bootloader-seeds-by-default.patch')
| -rw-r--r-- | 0045-random-credit-cpu-and-bootloader-seeds-by-default.patch | 195 |
1 files changed, 195 insertions, 0 deletions
diff --git a/0045-random-credit-cpu-and-bootloader-seeds-by-default.patch b/0045-random-credit-cpu-and-bootloader-seeds-by-default.patch new file mode 100644 index 000000000000..ca384a8c9535 --- /dev/null +++ b/0045-random-credit-cpu-and-bootloader-seeds-by-default.patch @@ -0,0 +1,195 @@ +From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 +From: "Jason A. Donenfeld" <Jason@zx2c4.com> +Date: Sun, 5 Jun 2022 18:30:46 +0200 +Subject: [PATCH] random: credit cpu and bootloader seeds by default + +[ Upstream commit 846bb97e131d7938847963cca00657c995b1fce1 ] + +This commit changes the default Kconfig values of RANDOM_TRUST_CPU and +RANDOM_TRUST_BOOTLOADER to be Y by default. It does not change any +existing configs or change any kernel behavior. The reason for this is +several fold. + +As background, I recently had an email thread with the kernel +maintainers of Fedora/RHEL, Debian, Ubuntu, Gentoo, Arch, NixOS, Alpine, +SUSE, and Void as recipients. I noted that some distros trust RDRAND, +some trust EFI, and some trust both, and I asked why or why not. There +wasn't really much of a "debate" but rather an interesting discussion of +what the historical reasons have been for this, and it came up that some +distros just missed the introduction of the bootloader Kconfig knob, +while another didn't want to enable it until there was a boot time +switch to turn it off for more concerned users (which has since been +added). The result of the rather uneventful discussion is that every +major Linux distro enables these two options by default. + +While I didn't have really too strong of an opinion going into this +thread -- and I mostly wanted to learn what the distros' thinking was +one way or another -- ultimately I think their choice was a decent +enough one for a default option (which can be disabled at boot time). +I'll try to summarize the pros and cons: + +Pros: + +- The RNG machinery gets initialized super quickly, and there's no + messing around with subsequent blocking behavior. + +- The bootloader mechanism is used by kexec in order for the prior + kernel to initialize the RNG of the next kernel, which increases + the entropy available to early boot daemons of the next kernel. + +- Previous objections related to backdoors centered around + Dual_EC_DRBG-like kleptographic systems, in which observing some + amount of the output stream enables an adversary holding the right key + to determine the entire output stream. + + This used to be a partially justified concern, because RDRAND output + was mixed into the output stream in varying ways, some of which may + have lacked pre-image resistance (e.g. XOR or an LFSR). + + But this is no longer the case. Now, all usage of RDRAND and + bootloader seeds go through a cryptographic hash function. This means + that the CPU would have to compute a hash pre-image, which is not + considered to be feasible (otherwise the hash function would be + terribly broken). + +- More generally, if the CPU is backdoored, the RNG is probably not the + realistic vector of choice for an attacker. + +- These CPU or bootloader seeds are far from being the only source of + entropy. Rather, there is generally a pretty huge amount of entropy, + not all of which is credited, especially on CPUs that support + instructions like RDRAND. In other words, assuming RDRAND outputs all + zeros, an attacker would *still* have to accurately model every single + other entropy source also in use. + +- The RNG now reseeds itself quite rapidly during boot, starting at 2 + seconds, then 4, then 8, then 16, and so forth, so that other sources + of entropy get used without much delay. + +- Paranoid users can set random.trust_{cpu,bootloader}=no in the kernel + command line, and paranoid system builders can set the Kconfig options + to N, so there's no reduction or restriction of optionality. + +- It's a practical default. + +- All the distros have it set this way. Microsoft and Apple trust it + too. Bandwagon. + +Cons: + +- RDRAND *could* still be backdoored with something like a fixed key or + limited space serial number seed or another indexable scheme like + that. (However, it's hard to imagine threat models where the CPU is + backdoored like this, yet people are still okay making *any* + computations with it or connecting it to networks, etc.) + +- RDRAND *could* be defective, rather than backdoored, and produce + garbage that is in one way or another insufficient for crypto. + +- Suggesting a *reduction* in paranoia, as this commit effectively does, + may cause some to question my personal integrity as a "security + person". + +- Bootloader seeds and RDRAND are generally very difficult if not all + together impossible to audit. + +Keep in mind that this doesn't actually change any behavior. This +is just a change in the default Kconfig value. The distros already are +shipping kernels that set things this way. + +Ard made an additional argument in [1]: + + We're at the mercy of firmware and micro-architecture anyway, given + that we are also relying on it to ensure that every instruction in + the kernel's executable image has been faithfully copied to memory, + and that the CPU implements those instructions as documented. So I + don't think firmware or ISA bugs related to RNGs deserve special + treatment - if they are broken, we should quirk around them like we + usually do. So enabling these by default is a step in the right + direction IMHO. + +In [2], Phil pointed out that having this disabled masked a bug that CI +otherwise would have caught: + + A clean 5.15.45 boots cleanly, whereas a downstream kernel shows the + static key warning (but it does go on to boot). The significant + difference is that our defconfigs set CONFIG_RANDOM_TRUST_BOOTLOADER=y + defining that on top of multi_v7_defconfig demonstrates the issue on + a clean 5.15.45. Conversely, not setting that option in a + downstream kernel build avoids the warning + +[1] https://lore.kernel.org/lkml/CAMj1kXGi+ieviFjXv9zQBSaGyyzeGW_VpMpTLJK8PJb2QHEQ-w@mail.gmail.com/ +[2] https://lore.kernel.org/lkml/c47c42e3-1d56-5859-a6ad-976a1a3381c6@raspberrypi.com/ + +Cc: Theodore Ts'o <tytso@mit.edu> +Reviewed-by: Ard Biesheuvel <ardb@kernel.org> +Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> +Signed-off-by: Sasha Levin <sashal@kernel.org> +--- + drivers/char/Kconfig | 50 +++++++++++++++++++++++++++----------------- + 1 file changed, 31 insertions(+), 19 deletions(-) + +diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig +index 55f48375e3fe5487d8ebb47a250b75dafa9ec61c..d454428f4981d1bb1e6af87f245a9644b8b5dbc3 100644 +--- a/drivers/char/Kconfig ++++ b/drivers/char/Kconfig +@@ -428,28 +428,40 @@ config ADI + driver include crash and makedumpfile. + + config RANDOM_TRUST_CPU +- bool "Trust the CPU manufacturer to initialize Linux's CRNG" ++ bool "Initialize RNG using CPU RNG instructions" ++ default y + depends on ARCH_RANDOM +- default n + help +- Assume that CPU manufacturer (e.g., Intel or AMD for RDSEED or +- RDRAND, IBM for the S390 and Power PC architectures) is trustworthy +- for the purposes of initializing Linux's CRNG. Since this is not +- something that can be independently audited, this amounts to trusting +- that CPU manufacturer (perhaps with the insistence or mandate +- of a Nation State's intelligence or law enforcement agencies) +- has not installed a hidden back door to compromise the CPU's +- random number generation facilities. This can also be configured +- at boot with "random.trust_cpu=on/off". ++ Initialize the RNG using random numbers supplied by the CPU's ++ RNG instructions (e.g. RDRAND), if supported and available. These ++ random numbers are never used directly, but are rather hashed into ++ the main input pool, and this happens regardless of whether or not ++ this option is enabled. Instead, this option controls whether the ++ they are credited and hence can initialize the RNG. Additionally, ++ other sources of randomness are always used, regardless of this ++ setting. Enabling this implies trusting that the CPU can supply high ++ quality and non-backdoored random numbers. ++ ++ Say Y here unless you have reason to mistrust your CPU or believe ++ its RNG facilities may be faulty. This may also be configured at ++ boot time with "random.trust_cpu=on/off". + + config RANDOM_TRUST_BOOTLOADER +- bool "Trust the bootloader to initialize Linux's CRNG" +- help +- Some bootloaders can provide entropy to increase the kernel's initial +- device randomness. Say Y here to assume the entropy provided by the +- booloader is trustworthy so it will be added to the kernel's entropy +- pool. Otherwise, say N here so it will be regarded as device input that +- only mixes the entropy pool. This can also be configured at boot with +- "random.trust_bootloader=on/off". ++ bool "Initialize RNG using bootloader-supplied seed" ++ default y ++ help ++ Initialize the RNG using a seed supplied by the bootloader or boot ++ environment (e.g. EFI or a bootloader-generated device tree). This ++ seed is not used directly, but is rather hashed into the main input ++ pool, and this happens regardless of whether or not this option is ++ enabled. Instead, this option controls whether the seed is credited ++ and hence can initialize the RNG. Additionally, other sources of ++ randomness are always used, regardless of this setting. Enabling ++ this implies trusting that the bootloader can supply high quality and ++ non-backdoored seeds. ++ ++ Say Y here unless you have reason to mistrust your bootloader or ++ believe its RNG facilities may be faulty. This may also be configured ++ at boot time with "random.trust_bootloader=on/off". + + endmenu |