linux-kernel - Re: [PATCH v43 01/15] Linux Random Number Generator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHmME9rmWBA02SyeFiiGZ8=kydYJSJwcYPscBrTBzoXMEPH9sQ@mail.gmail.com>
Date:   Mon, 10 Jan 2022 23:19:56 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     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>,
        LKML <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>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        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>,
        Andy Lutomirski <luto@...nel.org>,
        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 9:18 PM Theodore Ts'o <tytso@....edu> 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.

Jason

[1] https://lore.kernel.org/lkml/YdynXjhhuQfbYuSb@zx2c4.com/