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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yi1CRQ1rdQTxilCc@sol.localdomain>
Date:   Sat, 12 Mar 2022 17:00:53 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Theodore Ts'o <tytso@....edu>,
        Dominik Brodowski <linux@...inikbrodowski.net>
Subject: Re: [PATCH v2] random: reseed more often immediately after booting

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@...nel.org> 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