Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 6 Nov 2022 08:02:56 +0100
From:   Dominik Brodowski <linux@dominikbrodowski.net>
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org
Subject: Re: [PATCH v2] hw_random: use add_hwgenerator_randomness() for early
 entropy
Message-ID: <Y2dcIKWOmczDCGLG@owl.dominikbrodowski.net>
References: <CAHmME9r=xGdYa1n16TTgdfvzLkc==hGr+1v3eZmyzpEX+437uw@mail.gmail.com>
 <20221106015042.98538-1-Jason@zx2c4.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221106015042.98538-1-Jason@zx2c4.com>
Precedence: bulk

Am Sun, Nov 06, 2022 at 02:50:42AM +0100 schrieb Jason A. Donenfeld:
> Rather than calling add_device_randomness(), the add_early_randomness()
> function should use add_hwgenerator_randomness(), so that the early
> entropy can be potentially credited, which allows for the RNG to
> initialize earlier without having to wait for the kthread to come up.

We're already at device_initcall() level here, so that shouldn't be much of
an additional delay.

> Since we don't want to sleep from add_early_randomness(), we also
> refactor the API a bit so that hw_random/core.c can do the sleep, this
> time using the correct function, hwrng_msleep, rather than having
> random.c awkwardly do it.

Isn't this something you were quite hesistant about just recently[*]?

| I was thinking the other day that under certain circumstances, it
| would be nice if random.c could ask hwrng for more bytes NOW, rather
| than waiting. With the code as it is currently, this could be
| accomplished by having a completion event or something similar to
| that. With your proposed change, now it's left up to the hwrng
| interface to handle.
| 
| That's not the end of the world, but it does mean we'd have to come up
| with a patch down the line that exports a hwrng function saying, "stop
| the delays and schedule the worker NOW". Now impossible, just more
| complex, as now the state flow is split across two places. Wondering
| if you have any thoughts about this.

Thanks,
	Dominik

[*] https://lore.kernel.org/lkml/CAHmME9rhunb05DEnc=UfGr8k9_LBi1NW2Hi0OsRbGwcCN2NzjQ@mail.gmail.com/