linux-kernel - Re: [PATCH v36 00/13] /dev/random

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: <20201028180728.GA2831268@kroah.com>
Date:   Wed, 28 Oct 2020 19:07:28 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Torsten Duwe <duwe@....de>
Cc:     "Theodore Y. Ts'o" <tytso@....edu>,
        Stephan Müller <smueller@...onox.de>,
        Willy Tarreau <w@....eu>, linux-crypto@...r.kernel.org,
        Nicolai Stange <nstange@...e.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Vito Caputo <vcaputo@...garu.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>,
        Andy Lutomirski <luto@...nel.org>,
        Florian Weimer <fweimer@...hat.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        Peter Matthias <matthias.peter@....bund.de>,
        Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
        Neil Horman <nhorman@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Julia Lawall <julia.lawall@...ia.fr>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        And y Lavr <andy.lavr@...il.com>,
        Eric Biggers <ebiggers@...nel.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Petr Tesarik <ptesarik@...e.cz>, simo@...hat.com
Subject: Re: [PATCH v36 00/13] /dev/random - a new approach

On Wed, Oct 28, 2020 at 06:51:17PM +0100, Torsten Duwe wrote:
> On Mon, 19 Oct 2020 21:28:50 +0200
> Stephan Müller <smueller@...onox.de> wrote:
> [...]
> > * Sole use of crypto for data processing:
> [...]
> >  - The LRNG uses only properly defined and implemented cryptographic
> >    algorithms unlike the use of the SHA-1 transformation in the
> > existing /dev/random implementation.
> > 
> >  - Hash operations use NUMA-node-local hash instances to benefit large
> >    parallel systems.
> > 
> >  - LRNG uses limited number of data post-processing steps
> [...]
> > * Performance
> > 
> >  - Faster by up to 75% in the critical code path of the interrupt
> > handler depending on data collection size configurable at kernel
> > compile time - the default is about equal in performance with
> > existing /dev/random as outlined in [2] section 4.2.
> 
> [...]
> >  - ChaCha20 DRNG is significantly faster as implemented in the
> > existing /dev/random as demonstrated with [2] table 2.
> > 
> >  - Faster entropy collection during boot time to reach fully seeded
> >    level, including on virtual systems or systems with SSDs as
> > outlined in [2] section 4.1.
> > 
> > * Testing
> [...]
> 
> So we now have 2 proposals for a state-of-the-art RNG, and over a month
> without a single comment on-topic from any `get_maintainer.pl`
> 
> I don't want to emphasise the certification aspects so much. The
> interrelation is rather that those certifications require certain code
> features, features which are reasonable per se. But the current code is
> lagging way behind.
> 
> I see the focus namely on performance, scalability, testability and
> virtualisation. And it certainly is an advantage to use the code
> already present under crypto, with its optimisations, and not rely
> on some home brew.
> 
> Can we please have a discussion about how to proceed?
> Ted, Greg, Arnd: which approach would you prefer?

Greg and Arnd are not the random driver maintainers, as is now correctly
shown in the 5.10-rc1 MAINTAINERS file, so I doubt we (well at least I)
have any say here, sorry.

good luck!

greg k-h