Hi, all. I have a question about the interaction between cryptodev and the kernel crypto self-tests.
If I flip FIPS mode on ("fips=1" on the kernel command line), the self-tests run for all the crypto algorithms, and depending on the kernel version, non-FIPS-allowed algorithms (like twofish and camellia) become unavailable (their self-test routines return -EINVAL). I would expect, because of the self-test routine failure, that a failed algorithm would not be usable through /dev/crypto. If I induce a self-test failure in a FIPS-allowed algorithm (say, by changing a byte of the compiled-in known answer test for AES), the self-test mechanism in the crypto subsystem correctly reports that AES failed, and appears to not allow any AES-related transforms to be loaded/used (all the tests for the various AES modes return a -2 result code after aes-generic fails). After this happens, /dev/crypto can still perform AES operations (in all modes), somehow ignoring the results of the self-tests. I've also tested causing only, for example, cbc(aes) to fail its tests and found that I could still do cbc(aes) operations through /dev/crypto. I poked around a bit in the crypto subsystem trying to figure out why this might be the case, but I wasn't able to find out how cryptodev manages to allocate algorithm instances for algorithms that have failed their self-tests. If anybody has any insight, I'd certainly appreciate it. Thanks! -Dan Zimmerman — Daniel M. Zimmerman <d...@galois.com> Research and Engineering, Galois, Inc.
_______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel