linux-kernel - Re: [PATCH 1/2] 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: <20200901131623.GB1059@1wt.eu>
Date:   Tue, 1 Sep 2020 15:16:23 +0200
From:   Willy Tarreau <w@....eu>
To:     David Laight <David.Laight@...lab.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Sedat Dilek <sedat.dilek@...il.com>,
        George Spelvin <lkml@....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" <tytso@....edu>, Florian Westphal <fw@...len.de>,
        Marc Plumb <lkml.mplumb@...il.com>
Subject: Re: [PATCH 1/2] random32: make prandom_u32() output unpredictable

On Tue, Sep 01, 2020 at 01:10:18PM +0000, David Laight wrote:
> From: Willy Tarreau
> > Sent: 01 September 2020 07:43
> ...
> > +/*
> > + *	Generate some initially weak seeding values to allow
> > + *	the prandom_u32() engine to be started.
> > + */
> > +static int __init prandom_init_early(void)
> > +{
> > +	int i;
> > +	unsigned long v0, v1, v2, v3;
> > +
> > +	if (!arch_get_random_long(&v0))
> > +		v0 = jiffies;
> 
> Isn't jiffies likely to be zero here?

I don't know. But do we really care ? I'd personally have been fine
with not even assigning it in this case and leaving whatever was in
the stack in this case, though it could make some static code analyzer
unhappy.

Willy