On Sat, Mar 12, 2022 at 05:35:08PM -0700, Jason A. Donenfeld wrote:
> 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.
It's just increasing the reseed interval linearly with the uptime, with constant
factor 0.5. So if the last reseed happened at uptime=t, then the next reseed
will happen on the first request made with uptime >= 2*t.
>
> 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?
That seems strictly worse than what you have now (though still better than the
status quo, of course). The only motivation I can see is if we'd want to avoid
reseeds during the requests themselves for performance reasons. It seems that
that's not really an issue, though?
- Eric
