linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-kernel@vger.kernel.org, Dexuan Cui <decui@microsoft.com>,
	linux-crypto@vger.kernel.org,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH v2] Documentation: crypto: add info about "fips=" boot option
Date: Tue, 30 Mar 2021 15:44:02 -0700	[thread overview]
Message-ID: <YGOpssfbqaGSlCl1@gmail.com> (raw)
In-Reply-To: <f86bb75f-e593-5b2f-943a-db2129256eab@infradead.org>

On Tue, Mar 30, 2021 at 09:38:55AM -0700, Randy Dunlap wrote:
> On 3/29/21 10:29 PM, Eric Biggers wrote:
> > On Mon, Mar 29, 2021 at 10:06:51PM -0700, Randy Dunlap wrote:
> >> Having just seen a report of using "fips=1" on the kernel command line,
> >> I could not find it documented anywhere, so add some help for it.
> >>
> >> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> >> Cc: Dexuan Cui <decui@microsoft.com>
> >> Cc: linux-crypto@vger.kernel.org
> >> Cc: Eric Biggers <ebiggers@kernel.org>
> >> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> >> Cc: "David S. Miller" <davem@davemloft.net>
> >> Cc: Jonathan Corbet <corbet@lwn.net>
> >> Cc: linux-doc@vger.kernel.org
> >> ---
> >> Updates/corrections welcome.
> >>
> >> v2: drop comment that "fips_enabled can cause some tests to be skipped".
> >>
> >>  Documentation/admin-guide/kernel-parameters.txt |   14 ++++++++++++++
> >>  1 file changed, 14 insertions(+)
> >>
> >> --- linux-next-20210329.orig/Documentation/admin-guide/kernel-parameters.txt
> >> +++ linux-next-20210329/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -1370,6 +1370,20 @@
> >>  			See Documentation/admin-guide/sysctl/net.rst for
> >>  			fb_tunnels_only_for_init_ns
> >>  
> >> +	fips=		Format: { 0 | 1}
> >> +			Use to disable (0) or enable (1) FIPS mode.
> >> +			If enabled, any process that is waiting on the
> >> +			'fips_fail_notif_chain' will be notified of fips
> >> +			failures.
> >> +			This setting can also be modified via sysctl at
> >> +			/proc/sysctl/crypto/fips_enabled, i.e.,
> >> +			crypto.fips_enabled.
> >> +			If fips_enabled = 1 and a test fails, it will cause a
> >> +			kernel panic.
> >> +			If fips_enabled = 1, RSA test requires a key size of
> >> +			2K or larger.
> >> +			It can also effect which ECC curve is used.
> > 
> > This doesn't really explain why anyone would want to give this option.
> > What high-level thing is this option meant to be accomplishing?
> > That's what the documentation should explain.
> 
> Yes, clearly, even to me.
> 
> But I could not find anything in the kernel source tree that would help me
> explain that.  So to repeat:
> 
> >> Updates/corrections welcome.
> 
> thanks.
> -- 

I'm by no means an expert on this, but the main thing I have in mind is that
(IIUC) the "fips" option is only useful if your whole kernel binary is certified
as a "FIPS cryptographic module", *and* you actually need the FIPS compliance.
And the upstream kernel doesn't have a FIPS certification out of the box; that's
a task for specific Linux distributors like Red Hat, SUSE, Ubuntu, who get
specific kernel binaries certified.

So, compiling a kernel and using the "fips" option is useless by itself, as your
kernel image won't actually have a FIPS certification in that case anyway.

So, I would expect an explanation like that about under what circumstances the
"fips" option is actually useful and intended for.

The people who actually use this option should be able to explain it properly
though; the above is just my understanding...

- Eric

  reply	other threads:[~2021-03-30 22:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30  5:06 [PATCH v2] Documentation: crypto: add info about "fips=" boot option Randy Dunlap
2021-03-30  5:29 ` Eric Biggers
2021-03-30 16:38   ` Randy Dunlap
2021-03-30 22:44     ` Eric Biggers [this message]
2021-03-31  7:49       ` Stephan Mueller

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=YGOpssfbqaGSlCl1@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=decui@microsoft.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    /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).