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 21C273858422 for ; Wed, 27 Jul 2022 02:45:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21C273858422 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 26R2jdQJ009732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jul 2022 22:45:40 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id EEE9615C3434; Tue, 26 Jul 2022 22:45:38 -0400 (EDT) Date: Tue, 26 Jul 2022 22:45:38 -0400 From: "Theodore Ts'o" To: Rich Felker Cc: 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> <20220727021618.GK7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220727021618.GK7074@brightrain.aerifal.cx> X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, DKIM_INVALID, DKIM_SIGNED, KAM_DMARC_NONE, KAM_DMARC_STATUS, 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 02:45:54 -0000 On Tue, Jul 26, 2022 at 10:16:19PM -0400, Rich Felker wrote: > Last year I helped someone get musl up and running with EABI userspace > (all we support) on a pre-EABI kernel (2.6.18 or so?) on embedded > hardware in use in the field that could not be upgraded for hardware > support reasons. Assuming post-2014 kernel may be okay for > desktop/server distros but from my perspective it's pretty > unthinkable. Was that machine on the network in any way? Why did it need cryptographic keys in the first place? Sure, maybe there are some super-rare cases where you just *happen* to decide that you need to use ancient hardware to generate keys that are communicated over the serial console to sign official RPM packages for some distro --- but I would *hope* that the distro could afford to spring for hardware that wasn't antedeluvian. It's fair that there are stupid people out there who think that it's an OK thing to use software which is riddled with zero-days because they're too cheap to update their hardware. But my point is that if you are worrying about fallback to /dev/urandom being a security hole, what *other* security holes might exist on that system? I can understand the argument the machine shouldn't fail, which probably means you probably want to make sure the ancient code shouldn't block forever, even if they are generating RSA public/private keypairs for SSL certificates in their init.d scripts, milliseconds after being booted on CPU's so ancient that they don't support RDRAND. But let's be real here about how secure that system is **actually** going to be, even *if* the random number generator is perfect(tm) and bug-free(tm). Let's not kid ourselves. Cheers, - Ted