Hi,
Cryptodev does not uses tcrypt module to decide if an algorithm is
available or not. It just asks for an algorithm by name when the session
starts (ioctl.c/crypto_create_session) and if the kernel allocates the
algorithm then it is usable from cryptodev point of view.
A failed test in tcrypt will probably always fail, even through
cryptodev. You have to see why this is not the case for you. For example
you can have more than one implementation of the algorithm and only one
to fail. If the other one is good, then it will be used by cryptodev
automatically because this is the behaviour of kernel/crypto.
See /proc/crypto for registered algorithms. It lists good kernel
algorithms that were used at least once. A failed algorithm will trigger
some errors on dmesg and should not be seen on that list. An algorithm
that was never loaded will certainly not show up there (e.g. fresh boot,
no modprobe tcrypt).
Cristian S.
On 01/31/2015 08:40 PM, Daniel M. Zimmerman wrote:
> 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 <mailto: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
>
_______________________________________________
Cryptodev-linux-devel mailing list
Cryptodev-linux-devel@gna.org
https://mail.gna.org/listinfo/cryptodev-linux-devel
