[GIT PULL] random number generator fixes for 5.17-rc4

[GIT PULL] random number generator fixes for 5.17-rc4

[Jason A. Donenfeld]

Hi Linus,

Please pull the following fixes for 5.17-rc4. This week's pull contains fixes
for the crypto ~vuln I mentioned last week. There are extensive details about
it and some simple PoC code in the commit message of the first patch if you're
curious.

Code-wise, the change is both insubstantial and substantial. It is
insubstantial in that we're talking about removing over 400 lines of old code,
many of which are outdated comments, and replacing them with less than 90
lines, so it's not "big" on the additive side.  On the other hand, it is a
substantial change, as it's doing away with the heart of our entropy collector
that we've had in one form or another forever. It would seem fitting with the
times that we're able to replace gobs of old stuff from the 90s with a boring
cryptographic hash function.

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.

Thanks,
Jason


The following changes since commit dfd42facf1e4ada021b939b4e19c935dcdd55566:

  Linux 5.17-rc3 (2022-02-06 12:20:50 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git tags/random-5.17-rc4-for-linus

for you to fetch changes up to 966038a49e2b31ff9aa86862295be3915c51dbdd:

  random: make credit_entropy_bits() always safe (2022-02-08 11:53:05 +0100)

----------------------------------------------------------------
Jason A. Donenfeld (5):
      random: use computational hash for entropy extraction
      random: simplify entropy debiting
      random: use linear min-entropy accumulation crediting
      random: always wake up entropy writers after extraction
      random: make credit_entropy_bits() always safe

 drivers/char/random.c         | 499 +++++++-----------------------------------
 include/trace/events/random.h |  30 +--
 2 files changed, 86 insertions(+), 443 deletions(-)

Re: [GIT PULL] random number generator fixes for 5.17-rc4

[Linus Torvalds]

On Tue, Feb 8, 2022 at 7:07 AM Jason A. Donenfeld <Jason@zx2c4.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

Re: [GIT PULL] random number generator fixes for 5.17-rc4

[Jason A. Donenfeld]

Hi Linus,

On Tue, Feb 8, 2022 at 7:47 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> I think the changes look fine, but this definitely conceptually is a
> "new feature" to me, rather than some security fix.
> In contrast, as a 5.18 merge window pull request, this makes complete sense.

Okay, no problem. Coming your way for 5.18 then.

Regards,
Jason