linux-kernel - Re: FIPS-mode panic? (was Re: [PULL] modules)

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]

Date:	Mon, 15 Oct 2012 13:28:47 +0200
From:	Stephan Mueller <stephan.mueller@...ec.com>
To:	David Howells <dhowells@...hat.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	LKML <linux-kernel@...r.kernel.org>,
	Alex Lyashkov <umka@...udlinux.com>,
	Arnd Bergmann <arnd@...db.com>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	"David S. Miller" <davem@...emloft.net>,
	Dmitry Kasatkin <dmitry.kasatkin@...el.com>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	Josh Boyer <jwboyer@...hat.com>, linux-crypto@...r.kernel.org,
	Lucas De Marchi <lucas.demarchi@...fusion.mobi>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Milan Broz <mbroz@...hat.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: FIPS-mode panic? (was Re: [PULL] modules)

On 15.10.2012 09:50:54, +0200, David Howells <dhowells@...hat.com> wrote:

Hi David,

> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
>> Hmm. So this thing makes me wonder:
>>
>>         /* Not having a signature is only an error if we're strict. */
>>         if (err < 0 && fips_enabled)
>>                 panic("Module verification failed with error %d in FIPS mode\n",
>>                       err);
>>
>> do we really want to panic (even in fips_enabled mode)?
> 
> That's what the FIPS people want.  As I understand it, if there's some
> indication that the crypto stuff is compromised, the box should be shut down
> immediately.
> 
> I've added Stephan Mueller to see if he can illuminate further.
> 
> David
> 

The requirement for a FIPS 140-2 module is to disable the entire module
if any component of its self test or integrity test failed.

In the kernel, we have the FIPS 140-2 module of the kernel crypto API
(the API itself plus the relevant kernel modules implementing the
ciphers, block chaining modes, etc). Therefore, the requirement would be
translated into the following: the kernel crypto API must be disabled if
any of the self test or integrity tests failed. The self tests are the
known answer tests in the kernel crypto API test manager. The integrity
tests are the DSA signature checks of the kernel modules (at least the
kernel crypto API ones) plus the static kernel binary itself (for the
static kernel crypto API part -- this is done outside the kernel).

The requirement to disable the module implies that the module is
technically unavailable.

There are two solutions that were contemplated for disabling the module:
having a kind of global status of the crypto API that makes it
non-responsive in case of an integrity/self-test error. The other
solution is to simply terminate the entire kernel. As the former one
also will lead to a kernel failure eventually as many parts of the
kernel depend on the crypto API, the implementation of the latter option
was chosen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/