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
