From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Sasha Levin <sashal@kernel.org>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH AUTOSEL 5.17 37/43] random: credit cpu and bootloader seeds by default
Date: Tue, 14 Jun 2022 10:51:57 +0200 [thread overview]
Message-ID: <YqhMLdFUi9ioVuam@zx2c4.com> (raw)
In-Reply-To: <20220614020602.1098943-37-sashal@kernel.org>
Hi Sasha,
On Mon, Jun 13, 2022 at 10:05:56PM -0400, Sasha Levin wrote:
> From: "Jason A. Donenfeld" <Jason@zx2c4.com>
>
> [ Upstream commit 846bb97e131d7938847963cca00657c995b1fce1 ]
Two things regarding this commit:
1) If you're going to AUTOSEL this for 5.18, 5.17, and 5.15, then you
also need to do the same for 5.10 also.
2) If you're going to pick this commit, please also pick its follow-up,
e052a478a7daeca67664f7addd308ff51dd40654, which likewise should apply
to all four versions.
Thanks,
Jason
>
> 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 55f48375e3fe..d454428f4981 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
> --
> 2.35.1
>
next prev parent reply other threads:[~2022-06-14 8:52 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 2:05 [PATCH AUTOSEL 5.17 01/43] powerpc/kasan: Silence KASAN warnings in __get_wchan() Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 02/43] ASoC: nau8822: Add operation for internal PLL off and on Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 03/43] drm/amd/display: Read Golden Settings Table from VBIOS Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 04/43] drm/amd/display: Fix DMUB outbox trace in S4 (#4465) Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 05/43] drm/amdkfd: Use mmget_not_zero in MMU notifier Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 06/43] dma-debug: make things less spammy under memory pressure Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 07/43] ASoC: cs42l52: Fix TLV scales for mixer controls Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 08/43] ASoC: cs35l36: Update digital volume TLV Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 09/43] ASoC: cs53l30: Correct number of volume levels on SX controls Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 10/43] ASoC: cs42l52: Correct TLV for Bypass Volume Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 11/43] ASoC: cs42l56: Correct typo in minimum level for SX volume controls Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 12/43] ASoC: cs42l51: Correct minimum value for SX volume control Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 13/43] drm/amdkfd: add pinned BOs to kfd_bo_list Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 14/43] ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 15/43] quota: Prevent memory allocation recursion while holding dq_lock Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 16/43] ASoC: wm8962: Fix suspend while playing music Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 17/43] ASoC: es8328: Fix event generation for deemphasis control Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 18/43] ASoC: wm_adsp: Fix event generation for wm_adsp_fw_put() Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 19/43] Input: soc_button_array - also add Lenovo Yoga Tablet2 1051F to dmi_use_low_level_irq Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 20/43] scsi: vmw_pvscsi: Expand vcpuHint to 16 bits Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 21/43] scsi: lpfc: Resolve NULL ptr dereference after an ELS LOGO is aborted Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 22/43] scsi: lpfc: Fix port stuck in bypassed state after LIP in PT2PT topology Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 23/43] scsi: lpfc: Allow reduced polling rate for nvme_admin_async_event cmd completion Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 24/43] scsi: mpt3sas: Fix out-of-bounds compiler warning Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 25/43] scsi: ipr: Fix missing/incorrect resource cleanup in error case Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 26/43] scsi: pmcraid: Fix missing " Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 27/43] ALSA: hda/realtek - Add HW8326 support Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 28/43] virtio-mmio: fix missing put_device() when vm_cmdline_parent registration failed Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 29/43] nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 30/43] ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 31/43] net: ethernet: mtk_eth_soc: fix misuse of mem alloc interface netdev[napi]_alloc_frag Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 32/43] gcc-12: disable '-Wdangling-pointer' warning for now Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 33/43] mellanox: mlx5: avoid uninitialized variable warning with gcc-12 Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 34/43] gcc-12: disable '-Warray-bounds' universally for now Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 35/43] netfs: gcc-12: temporarily disable '-Wattribute-warning' " Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 36/43] MIPS: Loongson-3: fix compile mips cpu_hwmon as module build error Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 37/43] random: credit cpu and bootloader seeds by default Sasha Levin
2022-06-14 8:51 ` Jason A. Donenfeld [this message]
2022-06-14 12:46 ` Jason A. Donenfeld
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 38/43] gpio: dwapb: Don't print error on -EPROBE_DEFER Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 39/43] platform/x86/intel: Fix pmt_crashlog array reference Sasha Levin
2022-06-14 2:05 ` [PATCH AUTOSEL 5.17 40/43] platform/x86/intel: pmc: Support Intel Raptorlake P Sasha Levin
2022-06-14 2:06 ` [PATCH AUTOSEL 5.17 41/43] platform/x86: gigabyte-wmi: Add Z690M AORUS ELITE AX DDR4 support Sasha Levin
2022-06-14 2:06 ` [PATCH AUTOSEL 5.17 42/43] platform/x86: gigabyte-wmi: Add support for B450M DS3H-CF Sasha Levin
2022-06-14 2:06 ` [PATCH AUTOSEL 5.17 43/43] platform/x86/intel: hid: Add Surface Go to VGBS allow list Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YqhMLdFUi9ioVuam@zx2c4.com \
--to=jason@zx2c4.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®