[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wi3fRiQXynJrLvaD5DDqF0MzgX1xSGFSJS_2frwXT1E5Q@mail.gmail.com>
Date: Tue, 8 Feb 2022 10:47:29 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] random number generator fixes for 5.17-rc4
On Tue, Feb 8, 2022 at 7:07 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> Given that these fixes are for a security issue (albeit a probably relatively
> low grade one), sending this mid-cycle feels like the "responsible" thing to
> do, and 5.17 will resultantly have a more secure RNG. However, I also would
> understand that, diffstat not withstanding, you think this is a bit much and
> want to reject this pull until 5.18. Either way works for me, though I
> naturally lean heavily toward the former, hence making this pull request in
> the first place.
I think the changes look fine, but this definitely conceptually is a
"new feature" to me, rather than some security fix.
Using a hash instead of an LFSR sounds like the modern and sane thing
to do, and simplifies the code a lot. But I also don't think the old
LFSR model is broken in practice.
I don't think the pool leaking has been a real or realistic attack,
and when the issue is lack of any actual real entropy (which _has_
been an issue), I don't think it really changes anything in practice.
So I think this is improving the code, but I don't think the old
approach was so broken that there's much argument for a mid-rc update
like this (and if it was, we'd have to mark this cc:stable all the way
back).
In contrast, as a 5.18 merge window pull request, this makes complete sense.
Linus
Powered by blists - more mailing lists