Messages in this thread |  | | Date | Sun, 10 Apr 2022 16:03:22 -0700 | From | Eric Biggers <> | Subject | Re: [PATCH RFC v1 00/10] archs/random: fallback to using sched_clock() if no cycle counter |
| |
On Fri, Apr 08, 2022 at 08:21:35PM +0200, Jason A. Donenfeld wrote: > By my first guess, we have ktime_get_boottime_ns(), jiffies, and > sched_clock(). It seems like sched_clock() has already done a lot of > work in being always available with some incrementing value, falling > back to jiffies as necessary. So this series goes with that as a > fallback, for when the architecture doesn't define random_get_entropy in > its own way and when there's no working cycle counter.
Won't this interact badly with how try_to_generate_entropy() (a.k.a. the "Linus Jitter Dance") detects the presence of an appropriate timer currently?
stack.cycles = random_get_entropy();
/* Slow counter - or none. Don't even bother */ if (stack.cycles == random_get_entropy()) return;
So if random_get_entropy() always returns 0, then try_to_generate_entropy() won't run. However, if random_get_entropy() is even just a low-precision timer, then try_to_generate_entropy() will have a chance of running, since the timer might change between the two calls to random_get_entropy(). And if try_to_generate_entropy() does run, then it credits 1 bit of entropy for every iteration, regardless of the timer's precision.
This is an existing problem, but this patchset will make it worse, as it changes a lot of cases from "no timer" to "low precision timer".
Perhaps try_to_generate_entropy() should check the timer at least 3 times and verify that it changed each time?
- Eric
|  |