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 26263C433FE for ; Tue, 11 Jan 2022 15:10:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243447AbiAKPKp (ORCPT ); Tue, 11 Jan 2022 10:10:45 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:56196 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241778AbiAKPKp (ORCPT ); Tue, 11 Jan 2022 10:10:45 -0500 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 dfw.source.kernel.org (Postfix) with ESMTPS id 997EF61422; Tue, 11 Jan 2022 15:10:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEE4FC36AEB; Tue, 11 Jan 2022 15:10:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641913844; bh=McsMtOZ08KNWSnvYFOe9+6qopfWa4aTK73Luxx5P3hM=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=DNpfDhPldxCXoEMFoSG9T69ITKuzR7l5o1TUboM2eBnDVC96zyQuhCvY0FQk0uMFH EsbPXYK0j1b+Mt6gFfEPSKY3lAvfotrXpk1sTIRSSyey5rm1M1EEEjzpK2eoVSws0l 9Gv3yIIcoFSorx6q2a9SVQsnx1ii0vso+OawPTcn0Er3nqNRBtIooGWaR+8uJKNMhO 5aOqYCeXnq0QoF3/t+ip3aRutJ1Eo4MNdWvdM6LmH6FTFaTbdCF1gurJhSAcmxfuie 6DiVRKddngeHnkcKM6eNIaAjs5tGoZpFzLH3MYhHzmIRBnHCb9IcICCCJiCJGm0mDZ mRpbeQf+zihlQ== Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 9ACA627C005A; Tue, 11 Jan 2022 10:10:41 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute5.internal (MEProxy); Tue, 11 Jan 2022 10:10:41 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehfedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepvdelheejjeevhfdutdeggefftdejtdffgeevteehvdfgjeeiveei ueefveeuvdetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 44B3921E006E; Tue, 11 Jan 2022 10:10:39 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4569-g891f756243-fm-20220111.001-g891f7562 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20211210014337.xmin2lu5rhhe3b3t@valinor> <20220110132349.siplwka7yhe2tmwc@valinor> Date: Tue, 11 Jan 2022 07:10:18 -0800 From: "Andy Lutomirski" To: "Jason A. Donenfeld" Cc: "Theodore Ts'o" , "Marcelo Henrique Cerri" , "Simo Sorce" , "Greg Kroah-Hartman" , "Jeffrey Walton" , "Stephan Mueller" , "Linux Crypto Mailing List" , "Willy Tarreau" , "Nicolai Stange" , "Linux Kernel Mailing List" , "Arnd Bergmann" , "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , "Matthew Garrett" , "Vito Caputo" , "Andreas Dilger" , "Jan Kara" , "Ray Strode" , "William Jon McCann" , zhangjs , "Florian Weimer" , "Lennart Poettering" , "Peter Matthias" , "Neil Horman" , "Randy Dunlap" , "Julia Lawall" , "Dan Carpenter" , "Andy Lavr" , "Petr Tesarik" , "John Haxby" , "Alexander Lobakin" , "Jirka Hladky" , "Eric Biggers" Subject: Re: [PATCH v43 01/15] Linux Random Number Generator Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Tue, Jan 11, 2022, at 5:06 AM, Jason A. Donenfeld wrote: > Hi Andy, > > On Tue, Jan 11, 2022 at 2:44 AM Andy Lutomirski wrot= e: >> So let=E2=80=99s solve it for real. Have a driver (in a module) that > > Um, let's not. This really isn't something the kernel needs to solve > here at all. There's a viable userspace solution. I see that the > discussion of something finally slightly technical (as opposed to just > compliance BS) has nerd sniped you a bit, but keep in mind what the > actual overall picture is. This isn't something that needs to be done. > My little CUSE thing (which I'm happy to develop out a bit more, even) > has the intent of fulfilling a compliance checkbox and nothing more. > Can you develop your CUSE thing enough that it=E2=80=99s credibly safe a= gainst side channels? If so, fine. I admit this is all rather absurd. FIPS aware userspace can do whatever = it wants, and It should be aware that /dev/urandom IS NOT FIPS. What=E2=80=99s the pr= oblem? rand(3) isn=E2=80=99t FIPS either, but no one puts person-years = of effort into trying to paint it FIPS-colored