From mboxrd@z Thu Jan 1 00:00:00 1970 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 D25AAC433FE for ; Wed, 23 Feb 2022 17:57:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242804AbiBWR5l (ORCPT ); Wed, 23 Feb 2022 12:57:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235343AbiBWR5i (ORCPT ); Wed, 23 Feb 2022 12:57:38 -0500 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33BB93C728; Wed, 23 Feb 2022 09:57:09 -0800 (PST) Received: from cwcc.thunk.org (pool-108-7-220-252.bstnma.fios.verizon.net [108.7.220.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 21NHttsY015836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Feb 2022 12:55:55 -0500 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 25DFF15C0036; Wed, 23 Feb 2022 12:55:55 -0500 (EST) Date: Wed, 23 Feb 2022 12:55:55 -0500 From: "Theodore Ts'o" To: "Jason A. Donenfeld" Cc: Andy Lutomirski , Linux Kernel Mailing List , Linux Crypto Mailing List , linux-arch , Dinh Nguyen , Nick Hu , Max Filippov , Palmer Dabbelt , "David S . Miller" , Yoshinori Sato , Michal Simek , Borislav Petkov , Guo Ren , Geert Uytterhoeven , Joshua Kinard , David Laight , Dominik Brodowski , Eric Biggers , Ard Biesheuvel , Arnd Bergmann , Thomas Gleixner , Kees Cook , Lennart Poettering , Konstantin Ryabitsev , Linus Torvalds , Greg Kroah-Hartman Subject: Re: [PATCH v1] random: block in /dev/urandom Message-ID: References: <20220217162848.303601-1-Jason@zx2c4.com> <6e117393-9c2f-441c-9c72-62c209643622@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Wed, Feb 23, 2022 at 06:02:52PM +0100, Jason A. Donenfeld wrote: > > I think your analysis is a bit mismatched from the reality of the > situation. That reality is that cryptographic users still find > themselves using /dev/urandom, as that's been the "standard good > advice" for a very long time. And people are still encouraged to do > that, either out of ignorance or out of "compatibility". The > cryptographic problem is not going away. Or they open /dev/urandom because getrandom() and getentropy() isn't available on some OS's (all the world is not Linux, despite what the systemd folks like to believe), and some other OS's have a /dev/urandom-like device that they can open, and so it's just more convenient for application programers to open and read from /dev/urandom. > Fixing this issue means, yes, adding a 1 second delay to the small > group of init system users who haven't switched to using > getrandom(GRND_INSECURE) for that less common usage (who even are > those users actually?). That's not breaking compatibility or breaking > userspace or breaking anything; that's accepting the reality of _how_ > /dev/urandom is mostly used -- for crypto -- and making that usage > finally secure, at the expense of a 1 second delay for those other > users who haven't switched to getrandom(GRND_INSECURE) yet. That seems > like a _very_ small price to pay for eliminating a footgun. I agree. So long as we're only blocking for short amount of time, and only during early after the system was booted, people shouldn't care. The reason why we had to add the "gee-I-hope-this-jitterentropy-like- hack-is-actually-secure on all architectures but it's better than the alternatives people were trying to get Linus to adopt" was because there were systems were hanging for hours or days. - Ted