Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1049122pxm; Wed, 23 Feb 2022 16:50:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJwy6bE4iun050ii+0Xr1cN7Qm9mm2OrfOJt99JNcKSFk30jPw4W5pDp14lUSYSdOKUss0Na X-Received: by 2002:a63:9d85:0:b0:374:916e:4b19 with SMTP id i127-20020a639d85000000b00374916e4b19mr337105pgd.128.1645663827745; Wed, 23 Feb 2022 16:50:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645663827; cv=none; d=google.com; s=arc-20160816; b=SEkUmbzOQiz4W3ECuGNQ0G+mbeTlPWYxG8cbq/stwzwxq1rVqQ0D910wbwWz3BjBGL YQ0pKM/K1t5UyZudmLUyOCTJ4HejM3P8pSH1xsp9uE2nHp9YDd4b2ZYwXh1jmk9tCk6T apTmDiV6UHDhut0UCLXugkaNPuczyWGOpXU8k25hldA5AU41Gnk0nxfuSbW/WF//aEnW ltayT2hCDCAgmI4Ole6loOTrvM/Xp5Xr8jZdI/5SaRR20jqYhD+BQqbLZZfM/ggzNjRG MpBNdS1ljkR8zabMxTtFICT0L1WPDzX8IrTio9NpKEJumw4nCIJppzd+UmyBsgp0tAS3 XCTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=kwTxYPQkNVKaxRR4prU/+eav0Rtzt7kZhZbukQ2ztcU=; b=WmEMOQNARHLFAcUPqFlKmEg3vRDqMpYvmN7nSdQmEuNfnd6842nkNxuZfFWrzviMq/ mIuHR/TdudUSFRG+KRZg1jGvAHqymUDsORfwGBAR1y0AwOPWSB7Ri/JGIIgajQaenPVe sLjikh201WUCPP3sDMqFElWaEj++r4HziGAFXbwcmn9kHk3msNfbJ5UVdVqZ3wps1/wq YEA8J0D6gS5BGfDB4B8N7y+yER/5JdL662TUub37SYgW7wFiRxpXsVN994W+IPMF4wS3 B1P+/xHFWs4hw/13N34WGzMjnczlc8ZmHVTxBteznBZTP+f5a1sTrNgWCHHSqdgMVSBx PXkg== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-crypto-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id b4si1027915plr.18.2022.02.23.16.50.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Feb 2022 16:50:27 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-crypto-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-crypto-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 02D74F70E2; Wed, 23 Feb 2022 16:45:27 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242804AbiBWR5l (ORCPT + 99 others); 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: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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