On Wed, May 13, 2009 at 12:40:10PM -0400, Jarod Wilson wrote: > On Wednesday 13 May 2009 10:03:29 Herbert Xu wrote: > > On Wed, May 13, 2009 at 09:37:32AM -0400, Jarod Wilson wrote: > > > > > > The latter option is more or less what the patch at the start of this > > > thread did, although via a param to tcrypt, not keying off the fips > > > flag. If I were to modify the patch to drop the mod param usage, and > > > instead key off the fips flag to not exit, would that be acceptable > > > for committing until such time as the userspace interface is ready? > > > > Yes that sounds like the way to go. > > Okay, here it is. > > At present, the tcrypt module always exits with an -EAGAIN upon > successfully completing all the tests its been asked to run. In fips > mode, integrity checking is done by running all self-tests from the > initrd, and its much simpler to check the ret from modprobe for > success than to scrape dmesg and/or /proc/crypto. Simply stay > loaded, giving modprobe a retval of 0, if self-tests all pass and > we're in fips mode. > > A side-effect of tracking success/failure for fips mode is that in > non-fips mode, self-test failures will return the actual failure > return codes, rather than always returning -EAGAIN, which seems more > correct anyway. > > The tcrypt_test() portion of the patch is dependent on my earlier > pair of patches that skip non-fips algs in fips mode, at least to > achieve the fully intended behavior. > > Nb: testing this patch against the cryptodev tree revealed a test > failure for sha384, which I have yet to look into... > > Signed-off-by: Jarod Wilson <jarod@xxxxxxxxxx> > Acked-by: Neil Horman <nhorman@xxxxxxxxxxxxx> > -- 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
