From: Stephan Mueller Subject: Re: FIPS-mode panic? (was Re: [PULL] modules) Date: Mon, 15 Oct 2012 13:28:47 +0200 Message-ID: <507BF36F.10205@atsec.com> References: <87fw5m7ipz.fsf@rustcorp.com.au> <15269.1350287454@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Linus Torvalds , Rusty Russell , LKML , Alex Lyashkov , Arnd Bergmann , Dan Carpenter , "David S. Miller" , Dmitry Kasatkin , Herbert Xu , Josh Boyer , linux-crypto@vger.kernel.org, Lucas De Marchi , Matthew Garrett , Milan Broz , Ralf Baechle , Randy Dunlap , Sam Ravnborg To: David Howells Return-path: In-Reply-To: <15269.1350287454@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org On 15.10.2012 09:50:54, +0200, David Howells wrote: Hi David, > Linus Torvalds 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.