We looked at this very briefly a couple of years ago. In theory, there may be a way to achieve the goal as a loadable kernel module (a.k.a. device driver). The idea would be to have a kernel module that provides crypto support. This kernel module would be the FIPS object module, with the FIPS boundary drawn around the kernel module. This would be loaded at run time like any other device driver when FIPS mode needed to be enabled. There is likely some kernel work required to allow the ciphers in the kernel module to be injected into the crypto flow within the kernel. The other issue is getting the kernel to automatically run the FIPS integrity test on the module at load time. On 03/26/2015 10:57 AM, Steve Marquess wrote: > On 03/25/2015 06:26 PM, jonetsu at teksavvy.com wrote: >> On Wed, 25 Mar 2015 17:03:04 -0400 >> Steve Marquess <marquess at openssl.com> wrote: >> >>> I wasn't aware the Linux kernel (the real one, not proprietary >>> commercial derivatives) had a "FIPS" mode. Please enlighten me. >> It could very well be that the word 'mode' is not the right one. >> 'option' would perhaps be better. This article from 2009 sets the >> foundation: >> >> http://www.guerilla-ciso.com/archives/793 >> >> I wonder, 6 years later, what the kernel fips option implies. Maybe I >> could try to contact Neil Horman and?or look into the sources. > That reference gives a pretty good explanation. CONFIG_CRYPTO_FIPS > doesn't get you any closer to FIPS 140-2 validated kernel cryptography. > > Unfortunately FIPS 140-2 validation conflicts rather violently with open > source software (and with software engineering best practice in general, > for that matter). Even if some benevolent benefactor ponied up the > quarter megabuck it would take to do an open source based kernel crypto > validation, it would be fossilized code obsolete before the validation > was even approved. Linux got to be as good as it is due to constant > refinement and improvement; FIPS validation presumes that it is possible > to write perfect code in one shot and that the environment that code > runs in never changes. > > -Steve M. >
