From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by sourceware.org (Postfix) with ESMTPS id 70C453857005 for ; Wed, 27 Jul 2022 12:32:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 70C453857005 Received: from cwcc.thunk.org (pool-173-48-118-63.bstnma.fios.verizon.net [173.48.118.63]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 26RCW7M8001791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Jul 2022 08:32:08 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id BA1F915C3434; Wed, 27 Jul 2022 08:32:07 -0400 (EDT) Date: Wed, 27 Jul 2022 08:32:07 -0400 From: "Theodore Ts'o" To: Adhemerval Zanella Netto Cc: Rich Felker , Florian Weimer , Yann Droneaud , "Jason A. Donenfeld" , libc-alpha@sourceware.org, linux-crypto@vger.kernel, Michael@phoronix.com, jann@thejh.net Subject: Re: arc4random - are you sure we want these? Message-ID: References: <6bf352e9-1312-40de-4733-3219721b343c@linaro.org> <20220725153303.GF7074@brightrain.aerifal.cx> <878rohp2ll.fsf@oldenburg.str.redhat.com> <20220725174430.GI7074@brightrain.aerifal.cx> <20220725184929.GJ7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00, DKIM_INVALID, DKIM_SIGNED, KAM_DMARC_NONE, KAM_DMARC_STATUS, LIKELY_SPAM_BODY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2022 12:32:24 -0000 On Wed, Jul 27, 2022 at 08:34:17AM -0300, Adhemerval Zanella Netto wrote: > The only thing I am kinda worried is we will need to be judicious if > we aim to use arc4random internally for hardening, since on some pattern > usage and kernels we might hit some performance issues. For instance, > we will need to tune down some internal parameters for a glibc testing > because now on a somewhat recent kernel (5.15.0-41-generic) I am seeing > a 10 runtime increase which the change to use getrandom. Jason has > told it has been fixed upstream, but taking in consideration the box > is an updated Ubuntu 22.04, it might take some time to have this fix > propagated on all kernels out there. What I'd suggest is that we be a realistic about specific use cases. Are we talking about scientific simulations? You don't want to be using be using secure random number generation for that anyway, because most reputable scientists have this thing about repeatable experiments. Are we talking about key generation? How many keys per second is it really realistic that such a system would need to support?. How many SSL connections would it be *able* to support? And since a secure web server or VPN gateway is going to be on the network, then you're going to want the latest kernel fixes, since there have been quite a some Really Bad Security vulnerabilities that have been fixed just in the past week (especially if you care about FEDRAMP or PCI compliance) at which point, you'll get the new and improved getrandom(2). But even if you didn't take the latest kernels, I think you will find that if you actually benchmark how many queries per second a real-life secure web server or VPN gateway, even the original 5.15.0 /dev/random driver was plenty fast enough for real world cryptographic use cases. Sure, maybe numbers would look small on a low-end ARM system --- but how many secure web transactions or IPSEC/wireguard connections could such a low-end ARM system really support, *anyway*? One of the dirty little secrets of web sites who live and die by clickbait performance benchmark articles for advertising revenue is how rarely real life workloads really are bottlenecked by things like, say, file system or /dev/random benchmarks. Reading those articles are *fun*, for people who like to say that their systems' metrics are longer/faster/stronger/whatever, but it's rare that they actually impact real world use cases. More often than not, the bottleneck is elsewhere. Cheers, - Ted P.S. The newer /dev/random drier would probably help out people who do things like "dd if=/dev/urandom of=/dev/expensive-ssd-where-it-would-be-way-faster- and-less-destructive-of-write-wearout-to-use-hdparm-security-erase bs=4k" --- but that's not really relevant to the glibc arc4random() discussion. :-)