lkml.org 
[lkml]   [2022]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH RFC v1 00/10] archs/random: fallback to using sched_clock() if no cycle counter
    Hi Eric,

    On 4/11/22, Eric Biggers <ebiggers@kernel.org> wrote:
    > 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?

    What you've identified is actually already the case for platforms
    where the cycle counter is already just slow (and there are a few such
    platforms; my odroid C2 even exhibits this). As you identified, the
    cycle counter might already be too slow, yet we get [un]lucky and
    reach this code right on the cusp or a change.

    So the problem isn't new here, per say, for this patchset. But indeed
    perhaps we should consider adjusting the heuristics for that a bit in
    a separate patch. Your check three times idea seems like a good
    starting point, if you want to send a patch and we can poke at it.

    Jason

    \
     
     \ /
      Last update: 2022-04-11 01:31    [W:2.209 / U:1.744 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site