linux-kernel - Re: [PATCH 5.9 639/757] random32: make prandom

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: <20201027171102.GA15452@1wt.eu>
Date:   Tue, 27 Oct 2020 18:11:02 +0100
From:   Willy Tarreau <w@....eu>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Amit Klein <aksecurity@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Andy Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>, tytso@....edu,
        Florian Westphal <fw@...len.de>,
        Marc Plumb <lkml.mplumb@...il.com>,
        George Spelvin <lkml@....org>, Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 5.9 639/757] random32: make prandom_u32() output
 unpredictable

Hi Greg,

On Tue, Oct 27, 2020 at 02:54:49PM +0100, Greg Kroah-Hartman wrote:
> From: George Spelvin <lkml@....org>
> 
> [ Upstream commit c51f8f88d705e06bd696d7510aff22b33eb8e638 ]
> 
> Non-cryptographic PRNGs may have great statistical properties, but
> are usually trivially predictable to someone who knows the algorithm,
> given a small sample of their output.  An LFSR like prandom_u32() is
> particularly simple, even if the sample is widely scattered bits.
(...)

I'd have let it cook a bit longer into mainline before backporting it,
first it's not small (a bit border line by stable rules), and second,
considering how long we've been with the previous solution, there's no
emergency anymore. The risks are essentially at the build level though
(e.g.  include hell on exotic architectures, or obscure driver trying
to make use of one of the removed functions maybe).

On the other hand, given the amount of tests that run on the stable
queue, we'll quickly know! So we can probably keep it for now, but do
not hesitate to drop and postpone it if it causes any trouble so that
we have time to investigate. I'd rather not go through the previous
one's repeated breakage again!

Thanks,
Willy