linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simo Sorce <simo@redhat.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>,
	Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jeffrey Walton <noloader@gmail.com>,
	Stephan Mueller <smueller@chronox.de>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Willy Tarreau <w@1wt.eu>, Nicolai Stange <nstange@suse.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Alexander E. Patrakov" <patrakov@gmail.com>,
	"Ahmed S. Darwish" <darwish.07@gmail.com>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Vito Caputo <vcaputo@pengaru.com>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Jan Kara <jack@suse.cz>, Ray Strode <rstrode@redhat.com>,
	William Jon McCann <mccann@jhu.edu>,
	zhangjs <zachary@baishancloud.com>,
	Andy Lutomirski <luto@kernel.org>,
	Florian Weimer <fweimer@redhat.com>,
	Lennart Poettering <mzxreary@0pointer.de>,
	Peter Matthias <matthias.peter@bsi.bund.de>,
	Randy Dunlap <rdunlap@infradead.org>,
	Julia Lawall <julia.lawall@inria.fr>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Andy Lavr <andy.lavr@gmail.com>, Petr Tesarik <ptesarik@suse.cz>,
	John Haxby <john.haxby@oracle.com>,
	Alexander Lobakin <alobakin@mailbox.org>,
	Jirka Hladky <jhladky@redhat.com>,
	Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH v43 01/15] Linux Random Number Generator
Date: Mon, 10 Jan 2022 14:41:33 -0500	[thread overview]
Message-ID: <cdfd8173b1b343413b054957dc2984c27587495c.camel@redhat.com> (raw)
In-Reply-To: <CAHmME9pe-DxTcFcMtsNnLPcccoY+0gEysivZQszAusH1M8ThmA@mail.gmail.com>

On Mon, 2022-01-10 at 19:44 +0100, Jason A. Donenfeld wrote:
> On Mon, Jan 10, 2022 at 4:08 PM Marcelo Henrique Cerri
> <marcelo.cerri@canonical.com> wrote:
> > > Just to confirm, this little patch here gives you FIPS certification?
> > It does
> 
> On Mon, Jan 10, 2022 at 7:29 PM Eric Biggers <ebiggers@kernel.org> wrote:
> > Now, the idea of certifying the whole kernel as a FIPS cryptographic module is
> > stupid

Not that it is not the whole kernel, but a "module boundary" is drawn
around the crypto API and vicinity.
It would be really nice if this whole "boundary" could be built as a
single binary module to be loaded in the kernel in fips mode. That way
we could update the rest of the kernel w/o rebuilding the module, but
we are not there.

Rebuilding the kernel does technically invalidate certification however
NIST themselves tells people to care first about the security of the
systems as long as the vendor is undergoing or promising certification
of the patched kernel.

There is an assumption of good faith.

> Alright, so if that's the case, then what you ostensibly want is:
> a) Some cryptoapi users to use crypto_rng_get_bytes, as they already
> do now. (In a private thread with Simo, I pointed out a missing place
> and encouraged him to send a patch for that but none has arrived.)

I noted your point, just haven' had time to act on it.

> b) Userspace to use some other RNG.
> 
> (a) is basically already done.
> 
> (b) can be accomplished in userspace by just (i) disabling getrandom()
> (making it return ENOSYS), and then (ii) replacing the /dev/urandom
> path with a CUSE device or similar.

While this is technically possible it is not very helpful, as it
requires downstream patching of userspace programs, most of which do
not have either runtime nor compile time switches to change the used
random device.

> I suppose (b.i) might be able to be done with some bpf seccomp cgroup
> situation. Or, if that's problematic, somebody could propose a
> "disable getrandom(2)" cmdline option. That doesn't seem very hard.
> And (b.ii) could use combined inputs from /dev/urandom and whatever
> FIPSy userspace jitter entropy daemon you have.

It is simply easier to just patch /dev/[u]random/getrandom() to use a
certified DRBG in FIPS mode, although we also considered all the
options you mentioned we couldn't really find a good reason to add 
more work, and make a more complicated solution when it is simple to
wire up the correct DRBG to the random device userspace applications
use and is the de facto standard API for obtaining good random numbers.

> In order to prevent the actual security from regressing on this, all
> you have to do is ensure that you're always using at least 32 bytes
> from the kernel's real /dev/urandom, and then whatever you add on top
> of that becomes just for the certification aspect. As your various
> green compliance checkboxes change over time and per region, you can
> just swap out the extra-paper-pushing-bytes-on-top with whatever the
> particular requirements of a certification body are. And you get to do
> this all in userspace.

You can do the whole jitterbug in userspace, but that is simply not
efficient and too disruptive (the above patching of all downstream
usage).

> 
> Marcelo/Simo - could you tell me what you find deficient about that
> plan? It strikes me that this would give you maximum flexibility and
> pretty much accomplish the goals?

My goal is to deviate as little as possible both in kernel and user-
space from what upstreams do. Creating new interfaces is easy, making 
people use them is almost impossible. Witness the process in getting
people to use getrandom() 


Let me also add that NIST requirements are not capricious, they are
written by people that study entropy sources and random generation as
their job and know what they are doing, I err on the side of giving
them credit. The requirements set by the various 90A/90B/90C documents
are about raising the bar, to guarantee that random number generators
are actually "certifiably" good. There are entropy assessment performed
by the labs as part of the certification process to insure the random
source is a good source and does produce output that passes randomness
tests.  I personally think the kernel would benefit from implementing
those "checkboxes", it is basically like implementing a sane CI/CD and
testing environment.

To answer to Ted,
every certification program necessarily requires a certain amount of
bureaucracy, especially when governments are involved, but that doesn't
mean that it's all security theater.

The FIPS certification process has changed over the years as well not
just the requirements. Until a few years ago the requirement to use
FIPS certified cryptography could be waived, and because very few
consumer programs were certified a lot of agencies considered it just a
burden and didn't care much. That has changed, it is now required as a
matter of law for most government agencies, and the waiver process has
been discontinued. So we really need to provide FIPS certification to
our public sector customers, moreover various other security standards
now reference FIPS standards, so it is extending beyond government
agencies and their contractors.

FIPS is painful for us undergoing certification, but as a program it
also does have positive effects. We scrutinize all cryptographic
modules a lot more than we used to, we have a lot more testing than we
used to and a lot more confidence in the solidity of the provided
cryptography in the Linux world also thanks to this scrutiny. I wish
the certification process was less painful for sure, but I believe it
does add value when done sensibly.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc





  reply	other threads:[~2022-01-10 19:41 UTC|newest]

Thread overview: 101+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-21 16:39 [PATCH v43 00/15] /dev/random - a new approach Stephan Müller
2021-11-21 16:40 ` [PATCH v43 01/15] Linux Random Number Generator Stephan Müller
2021-11-21 17:23   ` Joe Perches
2021-11-21 22:42   ` Jason A. Donenfeld
2021-11-22  5:34     ` Stephan Mueller
2021-11-22  6:02       ` Greg Kroah-Hartman
2021-11-22  6:42         ` Stephan Mueller
2021-11-22  6:55           ` Greg Kroah-Hartman
2021-11-22 15:09             ` Simo Sorce
2021-11-22 21:06               ` Jeffrey Walton
2021-11-23  5:38                 ` Stephan Mueller
2021-11-26 15:42               ` Greg Kroah-Hartman
2021-11-22 16:56         ` John Haxby
2021-11-26 15:40           ` Greg Kroah-Hartman
2021-11-22 14:59     ` Simo Sorce
2021-11-26 15:44       ` Greg Kroah-Hartman
2021-11-26 16:15         ` Stephan Mueller
2021-11-26 16:22           ` Greg Kroah-Hartman
2021-11-29 15:31             ` Stephan Mueller
2021-11-29 16:25               ` Greg Kroah-Hartman
2021-11-29 16:50                 ` Stephan Mueller
2021-11-30 12:24                 ` Jeffrey Walton
2021-11-30 14:04                   ` Greg Kroah-Hartman
2021-11-30 14:31                     ` Simo Sorce
2021-11-30 15:45                       ` Greg Kroah-Hartman
2021-11-30 17:05                         ` Willy Tarreau
2021-11-30 17:08                         ` Simo Sorce
2021-11-30 18:15                         ` Eric Biggers
2021-11-30 18:39                           ` Jason A. Donenfeld
2021-11-30 19:41                             ` Simo Sorce
2021-12-01 16:02                               ` Jason A. Donenfeld
2021-12-01 17:19                                 ` Simo Sorce
2021-12-01 17:55                                   ` Boris Krasnovskiy
2021-12-01 18:05                                     ` Greg Kroah-Hartman
2021-12-01 18:24                                   ` Jason A. Donenfeld
2021-12-02  0:24                                     ` Jeffrey Walton
2021-12-02  7:12                                       ` Greg Kroah-Hartman
2021-12-02 15:50                                         ` John Haxby
2021-12-01 18:29                                   ` Jason A. Donenfeld
     [not found]                                 ` <BY5PR14MB3416DF44172D8F47D0B078A986689@BY5PR14MB3416.namprd14.prod.outlook.com>
2021-12-01 18:05                                   ` Greg Kroah-Hartman
2021-12-10  1:43                                 ` Marcelo Henrique Cerri
2021-12-10  6:46                                   ` Greg Kroah-Hartman
2021-12-10  9:30                                     ` Marcelo Henrique Cerri
2021-12-10  9:48                                       ` Greg Kroah-Hartman
2021-12-10 17:02                                         ` Simo Sorce
2021-12-11  7:06                                           ` Willy Tarreau
2021-12-11  8:09                                             ` Stephan Müller
2021-12-11  8:57                                               ` Willy Tarreau
2022-01-10 13:23                                   ` Marcelo Henrique Cerri
2022-01-10 14:11                                     ` Jason A. Donenfeld
2022-01-10 14:29                                       ` Theodore Ts'o
2022-01-10 14:38                                         ` Jason A. Donenfeld
2022-01-10 17:38                                           ` Theodore Ts'o
2022-01-10 18:29                                             ` Eric Biggers
2022-01-10 18:44                                               ` Jason A. Donenfeld
2022-01-10 19:41                                                 ` Simo Sorce [this message]
2022-01-10 20:05                                                   ` Eric Biggers
2022-01-10 19:49                                                 ` Theodore Ts'o
2022-01-10 22:19                                                   ` Jason A. Donenfeld
2022-01-11  1:44                                                     ` Andy Lutomirski
2022-01-11  3:10                                                       ` Theodore Ts'o
2022-01-11  4:04                                                         ` Willy Tarreau
2022-01-11  4:13                                                         ` Matthew Garrett
2022-01-11 10:01                                                           ` Alexander E. Patrakov
     [not found]                                                           ` <CAN_LGv0CTDi9k=t=TGHvaHZz5YVT+OUEBaRXjP=Xv=kousHY1w@mail.gmail.com>
2022-01-11 17:10                                                             ` Matthew Garrett
2022-01-11 13:16                                                         ` Jason A. Donenfeld
2022-01-11 16:08                                                           ` Theodore Ts'o
2022-01-11 13:06                                                       ` Jason A. Donenfeld
2022-01-11 15:10                                                         ` Andy Lutomirski
2022-01-10 21:38                                                 ` Jason A. Donenfeld
2022-01-10 15:07                                         ` Marcelo Henrique Cerri
2021-11-30 15:13                     ` Jeffrey Walton
2021-11-30 15:39                       ` Greg Kroah-Hartman
2021-11-30  7:32       ` Sandy Harris
2021-11-30  7:55         ` Greg Kroah-Hartman
2021-11-30  8:56           ` Stephan Mueller
2021-11-30  9:12             ` Greg Kroah-Hartman
2021-12-04  9:53           ` Sandy Harris
2021-11-22 10:33   ` kernel test robot
2021-11-22 11:47     ` Stephan Mueller
2021-11-25  5:25       ` [kbuild-all] " Chen, Rong A
2021-11-30  2:55         ` Sandy Harris
2021-11-30  6:06           ` Stephan Müller
2021-11-21 16:40 ` [PATCH v43 02/15] LRNG - IRQ entropy source Stephan Müller
2021-11-21 16:40 ` [PATCH v43 03/15] LRNG - sysctls and /proc interface Stephan Müller
2021-11-21 16:41 ` [PATCH v43 04/15] LRNG - allocate one DRNG instance per NUMA node Stephan Müller
2021-11-21 16:42 ` [PATCH v43 05/15] LRNG - CPU entropy source Stephan Müller
2021-11-22  7:09   ` kernel test robot
2021-11-22 11:48     ` Stephan Mueller
2021-11-21 16:42 ` [PATCH v43 06/15] LRNG - add switchable DRNG support Stephan Müller
2021-11-21 16:43 ` [PATCH v43 07/15] LRNG - add common generic hash support Stephan Müller
2021-11-21 16:43 ` [PATCH v43 08/15] crypto: DRBG - externalize DRBG functions for LRNG Stephan Müller
2021-11-21 16:44 ` [PATCH v43 09/15] LRNG - add SP800-90A DRBG extension Stephan Müller
2021-11-21 16:45 ` [PATCH v43 10/15] LRNG - add kernel crypto API PRNG extension Stephan Müller
2021-11-21 16:45 ` [PATCH v43 11/15] crypto: move Jitter RNG header include dir Stephan Müller
2021-11-21 16:46 ` [PATCH v43 12/15] LRNG - add Jitter RNG fast noise source Stephan Müller
2021-11-21 16:46 ` [PATCH v43 13/15] LRNG - add SP800-90B compliant health tests Stephan Müller
2021-11-21 16:47 ` [PATCH v43 14/15] LRNG - add interface for gathering of raw entropy Stephan Müller
2021-11-21 16:47 ` [PATCH v43 15/15] LRNG - add power-on and runtime self-tests Stephan Müller
2021-12-11 15:45 ` [PATCH v43 00/15] /dev/random - a new approach Thomas Schoebel-Theuer
2021-12-11 16:04   ` Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cdfd8173b1b343413b054957dc2984c27587495c.camel@redhat.com \
    --to=simo@redhat.com \
    --cc=Jason@zx2c4.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=alobakin@mailbox.org \
    --cc=andy.lavr@gmail.com \
    --cc=arnd@arndb.de \
    --cc=dan.carpenter@oracle.com \
    --cc=darwish.07@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=ebiggers@kernel.org \
    --cc=fweimer@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jack@suse.cz \
    --cc=jhladky@redhat.com \
    --cc=john.haxby@oracle.com \
    --cc=julia.lawall@inria.fr \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=marcelo.cerri@canonical.com \
    --cc=matthias.peter@bsi.bund.de \
    --cc=mccann@jhu.edu \
    --cc=mjg59@srcf.ucam.org \
    --cc=mzxreary@0pointer.de \
    --cc=noloader@gmail.com \
    --cc=nstange@suse.de \
    --cc=patrakov@gmail.com \
    --cc=ptesarik@suse.cz \
    --cc=rdunlap@infradead.org \
    --cc=rstrode@redhat.com \
    --cc=smueller@chronox.de \
    --cc=tytso@mit.edu \
    --cc=vcaputo@pengaru.com \
    --cc=w@1wt.eu \
    --cc=zachary@baishancloud.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).