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 

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.


-Dan Zimmerman

Daniel M. Zimmerman <d...@galois.com>
Research and Engineering, Galois, Inc.

Cryptodev-linux-devel mailing list

Reply via email to