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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ