Stephan Mueller <stephan.muel...@atsec.com> writes: > On 25.01.2013 00:36:01, +0100, Rusty Russell <ru...@rustcorp.com.au> wrote: >> "the module signature" here being the signature of any crypto module, >> I'm guessing from Kyle's awful patch. Any crypto module, or just some? >> Presumably any module used by any crypto module, too? > > Any module loading into the kernel crypto API must be caught and its > signature enforced. Thus Kyle's approach to catch the kernel crypto API > register function would be appropriate, if indeed we would catch all > crypto KOs that we want to catch -- see my remark to Kyle.
OK, so perhaps in fips mode we should fail the various crypto register calls if the kernel is tainted? > But that is not the focus of the FIPS test here. That test shall counter > accidental modifications (how unlikely they are). And I am fully aware > of the fact that this FIPS requirement does not make too much sense in > software implementations. Note, FIPS 140-2 mainly focuses on hardware > and has some requirements which are totally bogus for software -- this > is one of them. > > Well, but if we want to be FIPS 140-2 compliant, either we meet that > requirement, or, well, you are not compliant. It is that easy. :-) Two important principles here: 1) Ugliness and craziness must be contained in the subsystem which cares. 2) Minimize effort spent on craziness. Principle #1 means I want this in the crypto subsystem, not the module subsystem. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
