Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A61DCC433F5 for ; Sat, 11 Dec 2021 16:05:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231409AbhLKQFc (ORCPT ); Sat, 11 Dec 2021 11:05:32 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:48675 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S229953AbhLKQFb (ORCPT ); Sat, 11 Dec 2021 11:05:31 -0500 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 1BBG4Pcm006075; Sat, 11 Dec 2021 17:04:25 +0100 Date: Sat, 11 Dec 2021 17:04:25 +0100 From: Willy Tarreau To: Thomas Schoebel-Theuer Cc: Stephan =?iso-8859-1?Q?M=FCller?= , Tso Ted , linux-crypto@vger.kernel.org, Nicolai Stange , LKML , Arnd Bergmann , Greg Kroah-Hartman , "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , Matthew Garrett , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , Andy Lutomirski , Florian Weimer , Lennart Poettering , Peter Matthias , Marcelo Henrique Cerri , Neil Horman , Randy Dunlap , Julia Lawall , Dan Carpenter , Andy Lavr , Eric Biggers , "Jason A. Donenfeld" , Petr Tesarik , John Haxby , Alexander Lobakin , Jirka Hladky Subject: Re: [PATCH v43 00/15] /dev/random - a new approach Message-ID: <20211211160425.GA6023@1wt.eu> References: <2036923.9o76ZdvQCi@positron.chronox.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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