Date:   Tue, 11 Jan 2022 04:13:49 +0000
From:   Matthew Garrett <mjg59@...f.ucam.org>
To:     Theodore Ts'o <tytso@....edu>
Cc:     Andy Lutomirski <luto@...nel.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Marcelo Henrique Cerri <marcelo.cerri@...onical.com>,
        Simo Sorce <simo@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jeffrey Walton <noloader@...il.com>,
        Stephan Mueller <smueller@...onox.de>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Willy Tarreau <w@....eu>, Nicolai Stange <nstange@...e.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        Vito Caputo <vcaputo@...garu.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>,
        Florian Weimer <fweimer@...hat.com>,
        Lennart Poettering <mzxreary@...inter.de>,
        Peter Matthias <matthias.peter@....bund.de>,
        Neil Horman <nhorman@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Julia Lawall <julia.lawall@...ia.fr>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Andy Lavr <andy.lavr@...il.com>,
        Petr Tesarik <ptesarik@...e.cz>,
        John Haxby <john.haxby@...cle.com>,
        Alexander Lobakin <alobakin@...lbox.org>,
        Jirka Hladky <jhladky@...hat.com>,
        Eric Biggers <ebiggers@...nel.org>
Subject: Re: [PATCH v43 01/15] Linux Random Number Generator

On Mon, Jan 10, 2022 at 10:10:15PM -0500, Theodore Ts'o wrote:

> Right now, the enterprise distros are doing their own thing, and quite
> frankly, I don't see a problem with that.  If it turns out DRBG is
> less secure (and there are some things that fill me with disquiet),
> then let them take the economic consequences, since they are the ones
> who are doing this for the economic advantages of trying to claim FIPS
> compliance.

The goal is to identify a solution that avoids the enterprise kernels 
needing to do their own thing. They're in a position to globally 
LD_PRELOAD something to thunk getrandom() to improve compatibility if 
they want to, and they're also able to define the expected level of 
breakage if you enable FIPS mode. An approach that allows a single 
kernel to provide different policies in different contexts (eg, 
different namespaces could have different device nodes providing 
/dev/random) makes it easier to configure that based on customer 
requirements.

> If we must support this in the upstream kernel, then configure it via
> CONFIG_RANDOM_SECURITY_THEATRE which redirects getrandom(2) and
> /dev/[u]random to DRBG.  I'd prefer that it be possible for someone to
> put "random_security_theatre=0" on the boot command line which would
> disable redirecting the interfaces to DRBG so if it turns out that
> DRBG *is* less secure, we can give advice on how to turn it off
> without requiring a patched kernel.  :-)

The majority of enterprise customers don't need FIPS compliance, so all 
that would happen in that case is that the vendors would flip the sense 
of that config option and the docs for enterprise distros and mainline 
would be out of sync. I understand that this is a situation where a 
niche case is making life miserable for everyone else, and I understand 
that this is a hole that the enterprise world has dug for itself, but 
where there are people expressing a real tangible use case that exists 
for reasons outside their control, it really feels like we should try to 
find a solution that works for everyone.

Powered by blists - more mailing lists