| Message ID | 20220503195141.683217-1-Jason@zx2c4.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | random: mix hwgenerator randomness before sleeping | expand |
Am Tue, May 03, 2022 at 09:51:41PM +0200 schrieb Jason A. Donenfeld: > The add_hwgenerator_randomness() function is called in a loop from a > kthread by the hwgenerator core. It's supposed to sleep when there's > nothing to do, and wake up periodically for more entropy. Right now it > receives entropy, sleeps, and then mixes it in. This commit reverses the > order, so that it always mixes in entropy sooner and sleeps after. This > way the entropy is more fresh. ... however, the hwgenerator may take quite some time to accumulate entropy after wakeup. So now we might have a delay between a wakeup ("we need more entropy!") and that entropy becoming available. Beforehand, the thread only went to sleep when there is no current need for "fresh" entropy. Thanks, Dominik
Hi Dominik, On Tue, May 3, 2022 at 9:56 PM Dominik Brodowski <linux@dominikbrodowski.net> wrote: > > Am Tue, May 03, 2022 at 09:51:41PM +0200 schrieb Jason A. Donenfeld: > > The add_hwgenerator_randomness() function is called in a loop from a > > kthread by the hwgenerator core. It's supposed to sleep when there's > > nothing to do, and wake up periodically for more entropy. Right now it > > receives entropy, sleeps, and then mixes it in. This commit reverses the > > order, so that it always mixes in entropy sooner and sleeps after. This > > way the entropy is more fresh. > > ... however, the hwgenerator may take quite some time to accumulate entropy > after wakeup. So now we might have a delay between a wakeup ("we need more > entropy!") and that entropy becoming available. Beforehand, the thread only > went to sleep when there is no current need for "fresh" entropy. Huh, interesting consideration. I didn't think about that. You wrote, "hwgenerator may take quite some time to accumulate entropy" -- any idea how long in the worst case? A second? A minute? Jason
Hi Jason, Am Wed, May 04, 2022 at 02:45:46AM +0200 schrieb Jason A. Donenfeld: > On Tue, May 3, 2022 at 9:56 PM Dominik Brodowski > <linux@dominikbrodowski.net> wrote: > > > > Am Tue, May 03, 2022 at 09:51:41PM +0200 schrieb Jason A. Donenfeld: > > > The add_hwgenerator_randomness() function is called in a loop from a > > > kthread by the hwgenerator core. It's supposed to sleep when there's > > > nothing to do, and wake up periodically for more entropy. Right now it > > > receives entropy, sleeps, and then mixes it in. This commit reverses the > > > order, so that it always mixes in entropy sooner and sleeps after. This > > > way the entropy is more fresh. > > > > ... however, the hwgenerator may take quite some time to accumulate entropy > > after wakeup. So now we might have a delay between a wakeup ("we need more > > entropy!") and that entropy becoming available. Beforehand, the thread only > > went to sleep when there is no current need for "fresh" entropy. > > Huh, interesting consideration. I didn't think about that. You wrote, > "hwgenerator may take quite some time to accumulate entropy" -- any > idea how long in the worst case? A second? A minute? For TPM or virtio-rng, this shouldn't take long. But, for example, the Kconfig entry for HW_RANDOM_TIMERIOMEM states that This driver provides kernel-side support for a generic Random Number Generator used by reading a 'dumb' iomem address that is to be read no faster than, for example, once a second; the default FPGA bitstream on the TS-7800 has such functionality. Then, optee-rng.c contains a value "data_rate" in random bytes per second, and may sleep for a considerable time: msleep((1000 * (max - read)) / pvt_data->data_rate); Thanks, Dominik
Hi Dominik, Alright I'll drop this patch for now, and we can revisit it if we ever get rid of the premature next stuff. Jason
diff --git a/drivers/char/random.c b/drivers/char/random.c index 845f610b6611..d4eae4b167b4 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1154,6 +1154,9 @@ void rand_initialize_disk(struct gendisk *disk) void add_hwgenerator_randomness(const void *buffer, size_t count, size_t entropy) { + mix_pool_bytes(buffer, count); + credit_entropy_bits(entropy); + /* * Throttle writing if we're above the trickle threshold. * We'll be woken up again once below POOL_MIN_BITS, when @@ -1164,8 +1167,6 @@ void add_hwgenerator_randomness(const void *buffer, size_t count, !system_wq || kthread_should_stop() || input_pool.entropy_count < POOL_MIN_BITS, CRNG_RESEED_INTERVAL); - mix_pool_bytes(buffer, count); - credit_entropy_bits(entropy); } EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
The add_hwgenerator_randomness() function is called in a loop from a kthread by the hwgenerator core. It's supposed to sleep when there's nothing to do, and wake up periodically for more entropy. Right now it receives entropy, sleeps, and then mixes it in. This commit reverses the order, so that it always mixes in entropy sooner and sleeps after. This way the entropy is more fresh. Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- drivers/char/random.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)