On 15.10.2012 09:50:54, +0200, David Howells <dhowells@xxxxxxxxxx> wrote:
Hi David,
> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
