kernel: enable RANDOM_TRUST_BOOTLOADER on >= 5.4

[grahamc]

Some bootloaders can provide entropy to increase the kernel's initial device randomness.

This allows, for example, EFI to provide 64 bytes. In general my opinion is an attacker
who can manipulate the random seed sufficiently to cause problems likely has other,
more direct approaches at their disposal as well.

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[TredwellGit]

Is there an option to disable this without recompiling the kernel? As far as I am aware, the kernel already uses this as an entropy source without this being set and this option means that it completely trusts the UEFI random number generator to be not compromised and also be correct which is problematic because it can't be audited. I would actually advocate for the opposite options to be set -- we should explicitly not trust any unauditable random source. And this is not a theoretical concern; for example, there was recently an issue with AMD CPUs where RDRAND always returned 0xFFFFFFFFFFFFFFFF as a random output.

[mweinelt]

Apart from actual defects like this the bootloader is a crucial part of the bringup that if we can't trust we certainly have bigger problems. This was introduced in torvalds/linux@428826f and I don't see any obvious runtime switch you could toggle.

The bigger question is whether it would be the only source, and I don't think that is the case. Also we already trust the CPU RNG which we can't audit either, so the way I see it is: the more RNG sources the merrier.

[grahamc]

Is there an option to disable this without recompiling the kernel?

No. CONFIG_RANDOM_TRUST_CPU can be disabled with the random.trust_cpu cmdarg, but I'm sure you can imagine the bootloader gets to pick what arguments to send you, so an option to disable it isn't so helpful security-wise.

However, my understanding is measured boot measures if the bootloader's source is used, and policy decision can be made onthat.

As far as I am aware, the kernel already uses this as an entropy source without this being set and this option means that it completely trusts the UEFI random number generator to be not compromised and also be correct which is problematic because it can't be audited.

Not quite. I believe it only uses the bootloader's random seed as a part of the seeding of the RNG if this option is set, and it appears to only take 8 bytes:

/*
 * Handle random seed passed by bootloader.
 * If the seed is trustworthy, it would be regarded as hardware RNGs. Otherwise
 * it would be regarded as device data.
 * The decision is controlled by CONFIG_RANDOM_TRUST_BOOTLOADER.
 */
void add_bootloader_randomness(const void *buf, size_t size)
{
	if (IS_ENABLED(CONFIG_RANDOM_TRUST_BOOTLOADER))
		add_hwgenerator_randomness(buf, size, size * 8);

https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/tree/drivers/char/random.c#n1145

I would actually advocate for the opposite options to be set -- we should explicitly not trust any unauditable random source.

This is used as part of the generation of the initial state, and I don't think it is an exclusive source. With the exception of software bugs in the bootloader, can you imagine a scenario where this can go badly? I have a hard time imagining a case where it is worse than useless where an attacker isn't already extremely privileged to the point the RNG doesn't matter.

[TredwellGit]

See:
systemd/systemd#11810
RDRAND - not all is perfect in the AMD side of things :-/
https://en.wikipedia.org/wiki/Dual_EC_DRBG
https://en.wikipedia.org/wiki/RDRAND#Reception
https://blog.cr.yp.to/20140205-entropy.html

[grahamc]

Yes, the RDRAND issues were concerning, and it is very likely future hardware and software will have similar issues again. I don't yet consider that to be a compelling argument against using the data as part of a collection of random sources.

[TredwellGit]

My point is that you can't tell if there are bugs in unauditable random sources because they can provide output that is statistically random but in reality are not actually secure. There is also a continued effort to introduce intentionally malicious random number generators and that can be done in such a way that only the attacker is aware.

I don't trust these sources and already set random.trust_cpu=off and I really don't like an option like this where I have to recompile the kernel to change the setting.

[TredwellGit]

I also don't like these options because they blanket trust all CPU and bootloader random implementations even when there are implementations that are known to be broken in common use.

[grahamc]

It still isn't clear to me that your concerns hold up for 99% of use cases. I grant that there maybe such scenarios, but I don't believe our default kernel configuration should cater to them. Yes, AMD's RDRAND SNAFU was bad, but the kernel team has addressed it on their own. Regarding a hardware manufacturer compromising an RNG, I quite like what Theodore Ts'o had to say about this:

ultimately we have to trust the general purpose CPU. If the CPU is actively conspiring against you, there really is no hope.

Since cryptography and RNGs are such complex and delicate fields of study, I'm very cautious about reading much into unsubstantiated claims and scary hypotheticals. I'm also inclined to put my faith in the leaders of the field. In this case, Jason Donenfeld who brought this configuration to my attention.

As I mentioned earlier, I don't think an attack is very likely to exist which can meaningfully impact the early boot environment but is also predicated on compromising the RNG in some specific way. That, plus the ability to detect the usage of the data and prohibit it by policy using measured boot, and the ability to disable it and easily recompile the kernel, I'm quite inclined to apply this option.

[zx2c4]

https://lore.kernel.org/lkml/20220323041123.146459-1-Jason@zx2c4.com/ That might help with @TredwellGit's concerns.

[danderson]

+1 to Graham's analysis. If the firmware is compromised, there are many way easier and more powerful ways to compromise userspace than to futz with RNG init in the hopes that you have a better chance of predicting some early random bytes (prior to other system activity contributing more entropy and scrambling the state again). Doubly so if both TRUST_CPU and TRUST_BOOTLOADER are enabled, because now you need many different parties to have colluded and somehow kept it perfectly secret all these years.

Folks who have "I don't trust the hardware or firmware I run on" in their threat model can recompile their kernel if they feel that strongly about it. But should also reexamine their threat model, because really boot randomness is the least of anyone's worries if that's the starting point.