Re: [RFC PATCH 1/3] hw_random: allow RNG devices to give early randomness after a delay
From: Jason Cooper <hidden>
Date: 2014-07-14 12:37:16
Also in:
lkml
On Mon, Jul 14, 2014 at 10:05:19AM +0530, Amit Shah wrote:
quoted hunk ↗ jump to hunk
Some RNG devices may not be ready to give early randomness at probe() time, and hence lose out on the opportunity to contribute to system randomness at boot- or device hotplug- time. This commit schedules a delayed work item for such devices, and fetches early randomness after a delay. Currently the delay is 500ms, which is enough for the lone device that needs such treatment: virtio-rng. CC: Kees Cook <redacted> CC: Jason Cooper <redacted> CC: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Amit Shah <redacted> --- drivers/char/hw_random/core.c | 20 +++++++++++++++++++- include/linux/hw_random.h | 8 ++++++++ 2 files changed, 27 insertions(+), 1 deletion(-)diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index c4419ea..2a765fd 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/char/hw_random/core.c@@ -63,7 +63,7 @@ static size_t rng_buffer_size(void) return SMP_CACHE_BYTES < 32 ? 32 : SMP_CACHE_BYTES; } -static void add_early_randomness(struct hwrng *rng) +static void get_early_randomness(struct hwrng *rng) { unsigned char bytes[16]; int bytes_read;@@ -79,6 +79,21 @@ static void add_early_randomness(struct hwrng *rng) add_device_randomness(bytes, bytes_read); } +static void sched_init_random(struct work_struct *work) +{ + struct hwrng *rng = container_of(work, struct hwrng, dwork.work); + + get_early_randomness(rng); +} + +static void add_early_randomness(struct hwrng *rng)
The add/get naming seems awkward in the above hunks.
quoted hunk ↗ jump to hunk
+{ + if (!(rng->flags & HWRNG_DELAY_READ_AT_INIT)) + return get_early_randomness(rng); + + schedule_delayed_work(&rng->dwork, msecs_to_jiffies(500)); +} +
Perhaps instead of rng->flags and a hardcoded delay, we could have rng->seed_delay = msecs_to_jiffies(500) in virtio-rng? Then you can just call unconditionally: schedule_delayed_work(&rng->dwork, rng->seed_delay); I think that would be a more extensible solution should other drivers show up with the same issue. thx, Jason.