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 3C66C385843D for ; Wed, 27 Jul 2022 01:54:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3C66C385843D 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 26R1sUcv022193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jul 2022 21:54:32 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 7406F15C3434; Tue, 26 Jul 2022 21:54:30 -0400 (EDT) Date: Tue, 26 Jul 2022 21:54:30 -0400 From: "Theodore Ts'o" To: Rich Felker Cc: Cristian =?iso-8859-1?Q?Rodr=EDguez?= , Florian Weimer , Yann Droneaud , "Jason A. Donenfeld" , libc-alpha@sourceware.org, Michael@phoronix.com, jann@thejh.net, linux-crypto@vger.kernel 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: <20220725184929.GJ7074@brightrain.aerifal.cx> X-Spam-Status: No, score=-0.8 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 01:54:54 -0000 On Mon, Jul 25, 2022 at 02:49:30PM -0400, Rich Felker wrote: > > You can at least try the sysctl and possibly also /dev approaches and > only treat this as fatal as a last resort. If you can inspect > entropy_avail or poll /dev/random to determine that the pool is > initialized this is very safe, I think. And some research on distro > practices might uncover whether this should be believed to be > complete. I think people are *way* too worried about what happens if /dev/random is symlinked to /dev/urandom, and/or other bits of insanitry. The getrandom(3) system call has been around since v3.17. That's 2014. Even an ancient, obsolete enterprise distro like RHEL 7 backported the getrandom system call in 2017 --- a full 5 years ago. If someone is still using a pre-2017, or $DEITY help them, pre-2014 kernel, that kernel will be so riddled with zero-day vulnerabilities that some fallback to a /dev/urandom at boot time will be the ***least*** of their worries from a security perspective. And that's assuming someone who is so hide-bound as to be using a badly obsolete kernel would be interested in going to a bleeding edge libc in the first place! Similarly the LTS kernels have gotten backports of Jason's latest enhancements to the /dev/random driver. Someone who is using an out-of-date LTS kernel is similarly likely to be exposed to any number of zero-day vulnerabilities. Hence, the primary path that glibc should be concerned about, IMHO, should assume that getrandom(2) is (a) secure, and (b) fast. The other thing to note here is this really is an over-constrained problem. Some people will insist, strongly, that they need cryptographically secure random numbers, above all else. Others will insist that the interface for getting secure random numbers must never block. Still others will insist that they be able to use the crappiest CPU's, on systems with absolutely no entropy that can be harvested from I/O devices, and that they be able to generate mission- or -life critical cryptgraphic keys milliseconds after the user removes the consumer grade IOT device from the box, and plugs it into wall for the first time. It is ***impossible*** to satisfy all of these constraints. We do the best that we can in the kernel, but it's an order of magnitude harder to do it in userspace. So unless you want to cop-out by saying, "arcrandom isn't really secure, so when 10% of all devices reachable on the internet can breached, don't blame us", I strongly recommend that you leave things to the kernel. - Ted --- "Remember, the 'S' in IOT stands for security."