linux-kernel - Re: [PATCH] random: skip fast_init if hwrng provides large chunk of entropy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YjlwXxVWg1GNUR5J@owl.dominikbrodowski.net>
Date:   Tue, 22 Mar 2022 07:44:47 +0100
From:   Dominik Brodowski <linux@...inikbrodowski.net>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH] random: skip fast_init if hwrng provides large chunk of
 entropy

Am Mon, Mar 21, 2022 at 06:52:56PM -0600 schrieb Jason A. Donenfeld:
> At boot time, EFI calls add_bootloader_randomness(), which in turn calls
> add_hwgenerator_randomness(). Currently add_hwgenerator_randomness()
> feeds the first 64 bytes of randomness to the "fast init"
> non-crypto-grade phase. But if add_hwgenerator_randomness() gets called
> with more than POOL_MIN_BITS of entropy, there's no point in passing it
> off to the "fast init" stage, since that's enough entropy to bootstrap
> the real RNG.

Well, so far, we need 64 bytes input to the fast init stage, and then
further 32 bytes of randomness to proceed to full init, and we used to mix
the former into the latter, which provided for some sort of extra margin.
But as we don't seem to do that any more (mixing some of base_crng back into
the input_pool), that exercise may have become pointless.

However, it's noteworthy that then CONFIG_RANDOM_TRUST_BOOTLOADER really
means trusting it to possibly being the only source for the first generation
of base_crng. In the past, EFI-provided randnomness never was sufficient to
progress crng_init to 2.

Therefore, I am a bit torn about this patch.

Thanks,
	Dominik

NB: As POOL_MIN_BITS equals POOL_BITS, there's some room for cleanup. For
example, entropy_count cannot become larger than POOL_MIN_BITS in
credit_entropy_bits(), AFAICS.