Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220322005256.3787-1-Jason@zx2c4.com> <YjlwXxVWg1GNUR5J@owl.dominikbrodowski.net>
In-Reply-To: <YjlwXxVWg1GNUR5J@owl.dominikbrodowski.net>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Tue, 22 Mar 2022 11:25:48 -0600
Message-ID: <CAHmME9pBXXfhpGngu5GRVF8BRx57VYP4w4W9m=B33zW7AVE9Ng@mail.gmail.com>
Subject: Re: [PATCH] random: skip fast_init if hwrng provides large chunk of entropy
To:     Dominik Brodowski <linux@dominikbrodowski.net>
Cc:     LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Dominik,

On Tue, Mar 22, 2022 at 12:45 AM Dominik Brodowski
<linux@dominikbrodowski.net> wrote:
> 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.

"Some extra margin" but you're comparing 512 bits to 768 bits? That
makes no sense. 256 bits alone would be sufficient here. The whole
point of CONFIG_RANDOM_TRUST_BOOTLOADER=y is that the kernel builder
has chosen to trust the seed that comes from the bootloader. If it's
not trusted, then it goes through add_device_randomness(), which
doesn't have anything to do with fast init or the main init.

The purpose of "fast init" being separate from the full thing is so
that you can't brute force inputs bit by bit. Having a massive tranche
of 512 bits of entropy makes that brute forcing impossible; therefore
it doesn't make sense to do the fast init thing in that case.

Jason