Re: [PATCH v2] random: reseed more often immediately after booting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Eric,

On Sat, Mar 12, 2022 at 12:44 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> I don't think it's strange.  Maybe it seems strange because of how you wrote it
> ('interval = (5U << fls(uptime / 5)) * HZ'), where the reseed interval suddenly
> jumps from X to 2*X seconds.  The version I suggested is 'interval = max(5,
> uptime / 2) * HZ', which is smoother.  It's simply saying that the reseed
> interval increases as the uptime increases, which seems to be what we want.
> (Bounded by [5*HZ, CRNG_RESEED_INTERVAL], of course.)
> What you have now is still better than the status quo, but I'm not sure it's the
> best way.

To be clear, I'm not opposed to your suggestion. I just don't
understand it... yet. I've been playing around with this python script
to try to "see" what it's doing:

```
#!/usr/bin/env python3
import sys

stride = int(sys.argv[1])

lastyes = 0

def e(x):
    return max(5, x / 2)

def f(x):
    global lastyes
    if lastyes + e(x) - x < 0:
        lastyes = x
        return True
    return False

li = 0
for i in range(0, 300, stride):
    if f(i):
        print(i, i - li)
        li = i
```

And I can sort of see that for constant calls, it doubles the
frequency as you'd expect. But I still don't see how this is related
to system uptime in some definite way. The reason for having a
heuristic like this in the first place is that we are assuming that
there's some (inverse) correlation between the need for entropy and
the system boot time, and another correlation between the availability
of entropy and the system boot time. I'm just not "getting" how your
formula correlates to that. I'm not saying it's wrong, but just that I
might be a bit slow in grasping the relation. Can you give some more
details on what's happening? I'll continue to stare at it and poke
around with my python script of course, but if you could help that'd
be appreciated.

Alternatively, I had mentioned and then dismissed the timer approach
earlier, but actually maybe that'd be not as bad as I originally
thought? Just having a timer run at 5,10,20,40,80,160 or something
like that? Do you share my original allergy to that idea, or might
that actually be an okay way forward?

Jason



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux