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 801A4C433EF for ; Sun, 13 Feb 2022 03:16:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233093AbiBMDQE (ORCPT ); Sat, 12 Feb 2022 22:16:04 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:36732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233306AbiBMDQC (ORCPT ); Sat, 12 Feb 2022 22:16:02 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA61F5F25B for ; Sat, 12 Feb 2022 19:15:57 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 778D2B8085D for ; Sun, 13 Feb 2022 03:15:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56F15C340ED; Sun, 13 Feb 2022 03:15:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644722155; bh=cfBWan6cCytJstd6/pWGmDyKPrlRMs3PhvFLZb9flIA=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=n6JbxKlqcL0RAOuXM/wB7PjxNSkOwDc3Mk5RwS+gAaCsG9+WtOvtx0ANA+x9xFJ5w mbXMBbPJydMkjNn3FLkYFKafzV8vihxga6fQD0iDOLO2yVmsjCgk/MvdqjoPKAPQz6 moUjoQXuSLmC+ANubX4LzdHVEVmdRvZAWYJ3pRZMkZhSsk/ADJjfOtUffO6ea+L6vB 9BT9kvv7671cLvTM6lWU/wj4+wxhJktllZJ+gMIikltRcu5F7JxkwCEv7UrGC8fgO1 BY5P9IQyAXsSva1KrgyBvfSt5E+NDpbmKoZ+G262fdNB2d8RFvUGvsCwE2hVXPp4Jf hRCwPV49B1KYA== Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 1BF9027C0054; Sat, 12 Feb 2022 22:15:52 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute5.internal (MEProxy); Sat, 12 Feb 2022 22:15:53 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrieekgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetnhgu hicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenucggtf frrghtthgvrhhnpedvleehjeejvefhuddtgeegffdtjedtffegveethedvgfejieevieeu feevuedvteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedukeeh ieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinhhugi drlhhuthhordhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8F97C21E006E; Sat, 12 Feb 2022 22:15:51 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4748-g31a5b5f50e-fm-cal2020-20220204.001-g31a5b5f5 Mime-Version: 1.0 Message-Id: In-Reply-To: <20220211210757.612595-1-Jason@zx2c4.com> References: <20220211210757.612595-1-Jason@zx2c4.com> Date: Sat, 12 Feb 2022 19:15:31 -0800 From: "Andy Lutomirski" To: "Jason A. Donenfeld" , "Linux Kernel Mailing List" , "Linux Crypto Mailing List" Cc: "Paul Walmsley" , "Palmer Dabbelt" , "Albert Ou" , linux-riscv@lists.infradead.org, "Geert Uytterhoeven" , linux-m68k@lists.linux-m68k.org, "Thomas Bogendoerfer" , linux-mips@vger.kernel.org, "Dominik Brodowski" , "Eric Biggers" , "Ard Biesheuvel" , "Arnd Bergmann" , "Thomas Gleixner" , "Kees Cook" , "Lennart Poettering" , "Linus Torvalds" , "Greg Kroah-Hartman" , "Theodore Ts'o" Subject: Re: [PATCH RFC v0] random: block in /dev/urandom Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Fri, Feb 11, 2022, at 1:07 PM, Jason A. Donenfeld wrote: > This is very much an RFC patch, or maybe even an RFG -- request for > grumbles. This topic has come up a million times, and usually doesn't = go > anywhere. This time I thought I'd bring it up with a slightly narrower > focus. Before you read further, realize that I do not intend to merge > this without there being an appropriate amount of consensus for it and > discussion about it. > > Ever since Linus' 50ee7529ec45 ("random: try to actively add entropy > rather than passively wait for it"), the RNG does a haveged-style jitt= er > dance around the scheduler, in order to produce entropy (and credit it) > for the case when we're stuck in wait_for_random_bytes(). How ever you > feel about the Linus Jitter Dance is beside the point: it's been there > for three years and usually gets the RNG initialized in a second or so. I dislike this patch for a reason that has nothing to do with security. = Somewhere there=E2=80=99s a Linux machine that boots straight to Nethack= in a glorious 50ms. If Nethack gets 256 bits of amazing entropy from /= dev/urandom, then the machine=E2=80=99s owner has to play for real. If i= t repeats the same game on occasion, the owner can be disappointed or am= used. If it gets a weak seed that can be brute forced, then the owner ca= n have fun brute forcing it. If, on the other hand, it waits 750ms for enough jitter entropy to be pe= rfect, it=E2=80=99s a complete fail. No one wants to wait 750ms to play= Nethack. Replace Nethack with something with a backup camera or a lightbulb, both= of which have regulations related to startup time, and there may be a r= eal problem. Keep in mind that some language runtimes randomize their ha= sh table seeds at startup, possibly using /dev/urandom. This patch may b= reak actual, correct, working code.