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 <[email protected]>
Signed-off-by: Jason A. Donenfeld <[email protected]>
---
drivers/char/random.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
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);
--
2.35.1
Hi Dominik,
On Tue, May 3, 2022 at 9:56 PM Dominik Brodowski
<[email protected]> 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
> <[email protected]> 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
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