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 95EE6C433EF for ; Tue, 11 Jan 2022 01:44:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346240AbiAKBob (ORCPT ); Mon, 10 Jan 2022 20:44:31 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:40184 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243837AbiAKBoa (ORCPT ); Mon, 10 Jan 2022 20:44:30 -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 ams.source.kernel.org (Postfix) with ESMTPS id 8C4F7B81864; Tue, 11 Jan 2022 01:44:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ECD7FC36AF2; Tue, 11 Jan 2022 01:44:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641865468; bh=U1cLTMcj9acjC/ZshBrjqYKqAR1pltmGCBlmvDFjgqY=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=cwotnZKz9AaxK8JJI0wgjpXGcgnc92Hk5F17MZ7HZSrmX9tVF1sInLTi79CAdT+3z ithWHT49GprV+7Nev7MGVtP79seovvGATXcdQihjjlecaCOFtYdiVlNB9ttxcZ8fAr vHntJ638UEzrkvGhjpt/mxxiFs+pdr7yn61LEqvIurGtiYiO6U83UItwmDzyvPUG7p xdzpdbOKk8Yy5IrvBI7ETmwb43HPjSrO8zGzsyebobATQvg2CIbqICX4kvqTVBGwZ5 JczakWYaxAhvnAINmM77mnyvi6E/wKPFgvFnzzJrl/vpjpXJsyjIEKqaC17l+HxJxO MpzMd4XyPTi/g== Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id AF1D027C0054; Mon, 10 Jan 2022 20:44:25 -0500 (EST) Received: from imap48 ([10.202.2.98]) by compute5.internal (MEProxy); Mon, 10 Jan 2022 20:44:25 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehvddgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepuefgueefveekhedvtdffgfekleehgfekheevteegieekgeehiedv fffgjeetudfhnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhguhidomhgvshhmthhprghu thhhphgvrhhsohhnrghlihhthidqudduiedukeehieefvddqvdeifeduieeitdekqdhluh htoheppehkvghrnhgvlhdrohhrgheslhhinhhugidrlhhuthhordhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 781C321E006E; Mon, 10 Jan 2022 20:44:23 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4527-g032417b6d6-fm-20220109.002-g032417b6 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20211210014337.xmin2lu5rhhe3b3t@valinor> <20220110132349.siplwka7yhe2tmwc@valinor> Date: Mon, 10 Jan 2022 17:44:03 -0800 From: "Andy Lutomirski" To: "Jason A. Donenfeld" , "Theodore Ts'o" Cc: "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-kernel@vger.kernel.org On Mon, Jan 10, 2022, at 2:19 PM, Jason A. Donenfeld wrote: > On Mon, Jan 10, 2022 at 9:18 PM Theodore Ts'o wrote: >> In general, you need FIPS >> certification for some specific use cases / application. For example, >> if you're going for PCI compliance, then you might only need FIPS >> compliance for your OpenSSL library. What the FIPS certification lab >> might consider acceptable for its entropy for its DRBG is an >> interesting question. For some, simply having the OpenSSL library use >> RDSEED or RDRAND might be sufficient. Or it could talk to an actual >> physical RNG device. >> >> So disabling getrandom() is probably not necessary, just so long as >> you can demonstrate that the FIPS cryptographic module --- i.e., the >> OpenSSL library --- is getting its entropy from an acceptable source. > > I don't know exactly what these people think they want, but what you > say seems probably correct. > >> I suspect what's actually going on is that some enterprise customers >> have FIPS complaince on a check-off list, and they aren't actually >> getting a formal FIPS certification. Or they only need something to >> wave under the noses of their PCI certification company, and so the >> question is what makes them happy. > > Right. > >> And this is why some FIPS certification have gotten by just *fine* >> with a pure userspace OpenSSL library as their FIPS cryptographic >> module. Where you draw the line between a "blessed" entropy source >> and one that's just hand-waving is really at the discretion of the >> certification lab. > > Hah, probably correct. > > So, seen this way, and combined with the solution provided at [1] (or > similar) for people who think they need something there, it seems like > the FIPS people can likely get what they need without really needing > to involve the kernel anyway. Hmm, cute, but I think we can do a bit better. After all, this hack invo= lves trusting a whole lot of code that is *not* intended for secrets to = avoid having side channels. So let=E2=80=99s solve it for real. Have a driver (in a module) that ex= poses a /dev/urandom compatible interface to the CryptoAPI DRBG. We can= do a really nice job of it, and maybe it=E2=80=99ll be 100 lines of cod= e. People can do whatever they like with it in their container manager = or boot scripts. And if it has a problem (where it=E2=80=99s *less* secu= re than the real urandom), we can say =E2=80=9CI told you so=E2=80=9D. We can go one step farther: add an LSM hook to getrandom(). Then someon= e can hack up a fips_t policy for SELinux that turns off getrandom. > > Jason > > [1] https://lore.kernel.org/lkml/YdynXjhhuQfbYuSb@zx2c4.com/