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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 11 Dec 2021 17:04:25 +0100
From:   Willy Tarreau <w@....eu>
To:     Thomas Schoebel-Theuer <tst@...oebel-theuer.de>
Cc:     Stephan Müller <smueller@...onox.de>,
        Tso Ted <tytso@....edu>, linux-crypto@...r.kernel.org,
        Nicolai Stange <nstange@...e.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "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>,
        Andy Lavr <andy.lavr@...il.com>,
        Eric Biggers <ebiggers@...nel.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Petr Tesarik <ptesarik@...e.cz>,
        John Haxby <john.haxby@...cle.com>,
        Alexander Lobakin <alobakin@...lbox.org>,
        Jirka Hladky <jhladky@...hat.com>
Subject: Re: [PATCH v43 00/15] /dev/random - a new approach

On Sat, Dec 11, 2021 at 04:45:55PM +0100, Thomas Schoebel-Theuer wrote:
> 4) Collection of entropy vs consumption of entropy: the old /dev/random has
> an important feature for me: any _mass_ usage by whatever class of users
> (whether tenthousands of UIDs per server and/or HTTP/second, or maybe even
> some privileged orchestration scripts) would _consume_ masses of entropy.
> When suchalike consumption would exceed the production rate, the old
> /dev/random would become so slow that our internal monitoring processes
> would certainly alert, and consequently would hint our responsibles (located
> at other teams) at the problem.

I'm sorry but I cannot agree with you on this. You are claiming that your
monitoring processes are so limited that the only situation they can
discover is when the machine is basically dead. There are plenty of
users who end up replacing /dev/random with /dev/urandom in production
to make sure a terrible service outage never happens again, and one
important feature of an RNG is its performance, particularly when it's
shared between processes and users. The fact that your monitoring only
triggers when the system becomes unusable is a proof that it must be
fixed, and certainly not an indication that any possible kernel
limitation you're benefitting from does not deserve to be addressed.

Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ