From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 3DC6F385843D for ; Wed, 27 Jul 2022 02:16:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3DC6F385843D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=libc.org Date: Tue, 26 Jul 2022 22:16:19 -0400 From: Rich Felker To: Theodore Ts'o 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: <20220727021618.GK7074@brightrain.aerifal.cx> 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: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TVD_SUBJ_NUM_OBFU_MINFP, 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:16:22 -0000 On Tue, Jul 26, 2022 at 09:54:30PM -0400, Theodore Ts'o via Libc-alpha wrote: > 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. 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. > 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! There's a huge difference in zero-day vulnerabilities which might exist nowhere but on a box that's not exposed to the outside world, and possibly creating compromised key material from said boxes. And weird embedded stuff that can't be upgraded is *also* the same setting where you have a complete lack of early boot entropy. I'm fine with folks who need this stuff coming to musl instead of glibc, but I think folks on the glibc side are doing right to at least *consider* whether/how it matters rather than writing anything older than a few years off as irrelevant. Rich