kernel: enable RANDOM_TRUST_BOOTLOADER on >= 5.4 by grahamc · Pull Request #165355 · NixOS/nixpkgs

grahamc · 2022-03-23T02:01:59Z

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

> 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.

TredwellGit · 2022-03-23T02:18:36Z

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 · 2022-03-23T02:27:53Z

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 · 2022-03-23T02:30:12Z

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 · 2022-03-23T02:32:53Z

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 · 2022-03-23T02:38:03Z

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 · 2022-03-23T02:48:00Z

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 · 2022-03-23T02:59:30Z

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 · 2022-03-23T03:17:56Z

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 · 2022-03-23T04:13:27Z

https://lore.kernel.org/lkml/[email protected]/ That might help with @TredwellGit's concerns.

If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND. But, the user can disable (or enable) this behavior by setting `random.trust_cpu=0/1` on the kernel command line. This allows system builders to do reasonable things while avoiding howls from tinfoil hatters. (Or vice versa.) CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards the seed passed via EFI or device tree, which might come from RDRAND or a TPM or somewhere else. In order to allow distros to more easily enable this while avoiding those same howls (or vice versa), this commit adds the corresponding `random.trust_bootloader=0/1` toggle. Cc: Dominik Brodowski <[email protected]> Cc: Theodore Ts'o <[email protected]> Cc: Graham Christensen <[email protected]> Link: NixOS/nixpkgs#165355 Signed-off-by: Jason A. Donenfeld <[email protected]>

danderson · 2022-03-23T04:29:21Z

+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.

If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND. But, the user can disable (or enable) this behavior by setting `random.trust_cpu=0/1` on the kernel command line. This allows system builders to do reasonable things while avoiding howls from tinfoil hatters. (Or vice versa.) CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards the seed passed via EFI or device tree, which might come from RDRAND or a TPM or somewhere else. In order to allow distros to more easily enable this while avoiding those same howls (or vice versa), this commit adds the corresponding `random.trust_bootloader=0/1` toggle. Cc: Theodore Ts'o <[email protected]> Cc: Graham Christensen <[email protected]> Reviewed-by: Dominik Brodowski <[email protected]> Link: NixOS/nixpkgs#165355 Signed-off-by: Jason A. Donenfeld <[email protected]>

If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND. But, the user can disable (or enable) this behavior by setting `random.trust_cpu=0/1` on the kernel command line. This allows system builders to do reasonable things while avoiding howls from tinfoil hatters. (Or vice versa.) CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards the seed passed via EFI or device tree, which might come from RDRAND or a TPM or somewhere else. In order to allow distros to more easily enable this while avoiding those same howls (or vice versa), this commit adds the corresponding `random.trust_bootloader=0/1` toggle. Cc: Theodore Ts'o <[email protected]> Cc: Graham Christensen <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Reviewed-by: Dominik Brodowski <[email protected]> Link: NixOS/nixpkgs#165355 Signed-off-by: Jason A. Donenfeld <[email protected]>

commit d97c68d178fbf8aaaf21b69b446f2dfb13909316 upstream. If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND. But, the user can disable (or enable) this behavior by setting `random.trust_cpu=0/1` on the kernel command line. This allows system builders to do reasonable things while avoiding howls from tinfoil hatters. (Or vice versa.) CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards the seed passed via EFI or device tree, which might come from RDRAND or a TPM or somewhere else. In order to allow distros to more easily enable this while avoiding those same howls (or vice versa), this commit adds the corresponding `random.trust_bootloader=0/1` toggle. Cc: Theodore Ts'o <[email protected]> Cc: Graham Christensen <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Reviewed-by: Dominik Brodowski <[email protected]> Link: NixOS/nixpkgs#165355 Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…rust toggle commit d97c68d178fbf8aaaf21b69b446f2dfb13909316 upstream. If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND. But, the user can disable (or enable) this behavior by setting `random.trust_cpu=0/1` on the kernel command line. This allows system builders to do reasonable things while avoiding howls from tinfoil hatters. (Or vice versa.) CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards the seed passed via EFI or device tree, which might come from RDRAND or a TPM or somewhere else. In order to allow distros to more easily enable this while avoiding those same howls (or vice versa), this commit adds the corresponding `random.trust_bootloader=0/1` toggle. Cc: Theodore Ts'o <[email protected]> Cc: Graham Christensen <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Reviewed-by: Dominik Brodowski <[email protected]> Link: NixOS/nixpkgs#165355 Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Cyber Knight <[email protected]>

commit d97c68d178fbf8aaaf21b69b446f2dfb13909316 upstream. If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND. But, the user can disable (or enable) this behavior by setting `random.trust_cpu=0/1` on the kernel command line. This allows system builders to do reasonable things while avoiding howls from tinfoil hatters. (Or vice versa.) CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards the seed passed via EFI or device tree, which might come from RDRAND or a TPM or somewhere else. In order to allow distros to more easily enable this while avoiding those same howls (or vice versa), this commit adds the corresponding `random.trust_bootloader=0/1` toggle. Cc: Theodore Ts'o <[email protected]> Cc: Graham Christensen <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Reviewed-by: Dominik Brodowski <[email protected]> Link: NixOS/nixpkgs#165355 Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…rust toggle commit d97c68d178fbf8aaaf21b69b446f2dfb13909316 upstream. If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND. But, the user can disable (or enable) this behavior by setting `random.trust_cpu=0/1` on the kernel command line. This allows system builders to do reasonable things while avoiding howls from tinfoil hatters. (Or vice versa.) CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards the seed passed via EFI or device tree, which might come from RDRAND or a TPM or somewhere else. In order to allow distros to more easily enable this while avoiding those same howls (or vice versa), this commit adds the corresponding `random.trust_bootloader=0/1` toggle. Cc: Theodore Ts'o <[email protected]> Cc: Graham Christensen <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Reviewed-by: Dominik Brodowski <[email protected]> Link: NixOS/nixpkgs#165355 Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Cyber Knight <[email protected]>

commit d97c68d178fbf8aaaf21b69b446f2dfb13909316 upstream. If CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND. But, the user can disable (or enable) this behavior by setting `random.trust_cpu=0/1` on the kernel command line. This allows system builders to do reasonable things while avoiding howls from tinfoil hatters. (Or vice versa.) CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regards the seed passed via EFI or device tree, which might come from RDRAND or a TPM or somewhere else. In order to allow distros to more easily enable this while avoiding those same howls (or vice versa), this commit adds the corresponding `random.trust_bootloader=0/1` toggle. Cc: Theodore Ts'o <[email protected]> Cc: Graham Christensen <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Reviewed-by: Dominik Brodowski <[email protected]> Link: NixOS/nixpkgs#165355 Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

github-actions bot added the 6.topic: kernel The Linux kernel label Mar 23, 2022

grahamc requested a review from NeQuissimus March 23, 2022 02:03

mweinelt requested review from Atemu, Ma27, TredwellGit and alyssais March 23, 2022 02:03

grahamc force-pushed the random-trust-bootloader branch from 166849d to a5c2827 Compare March 23, 2022 02:05

zx2c4 approved these changes Mar 23, 2022

View reviewed changes

alyssais approved these changes Mar 23, 2022

View reviewed changes

grahamc merged commit e492708 into master Mar 24, 2022

grahamc deleted the random-trust-bootloader branch March 24, 2022 13:15

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

kernel: enable RANDOM_TRUST_BOOTLOADER on >= 5.4#165355

kernel: enable RANDOM_TRUST_BOOTLOADER on >= 5.4#165355
grahamc merged 1 commit intomasterfrom
random-trust-bootloader

grahamc commented Mar 23, 2022 •

edited

Loading

Uh oh!

TredwellGit commented Mar 23, 2022

Uh oh!

mweinelt commented Mar 23, 2022 •

edited

Loading

Uh oh!

grahamc commented Mar 23, 2022 •

edited

Loading

Uh oh!

TredwellGit commented Mar 23, 2022

Uh oh!

grahamc commented Mar 23, 2022

Uh oh!

TredwellGit commented Mar 23, 2022

Uh oh!

TredwellGit commented Mar 23, 2022

Uh oh!

grahamc commented Mar 23, 2022 •

edited

Loading

Uh oh!

zx2c4 commented Mar 23, 2022

Uh oh!

danderson commented Mar 23, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

grahamc commented Mar 23, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of changes

Things done

Uh oh!

TredwellGit commented Mar 23, 2022

Uh oh!

mweinelt commented Mar 23, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

grahamc commented Mar 23, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TredwellGit commented Mar 23, 2022

Uh oh!

grahamc commented Mar 23, 2022

Uh oh!

TredwellGit commented Mar 23, 2022

Uh oh!

TredwellGit commented Mar 23, 2022

Uh oh!

grahamc commented Mar 23, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zx2c4 commented Mar 23, 2022

Uh oh!

danderson commented Mar 23, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

grahamc commented Mar 23, 2022 •

edited

Loading

mweinelt commented Mar 23, 2022 •

edited

Loading

grahamc commented Mar 23, 2022 •

edited

Loading

grahamc commented Mar 23, 2022 •

edited

Loading