Hi, On Mon, Apr 27, 2015 at 02:08:29PM +0200, JM wrote: > Hello, > > Thank you for the quick reply. > > I use the mv_cesa driver as shipped by Debian with the 3.16 kernel, which > is almost certainly the same as mainline. > > I tried to run the _comp tools with mv_cesa removed: > > fijam@yukikaze:~/cryptodev-linux-1.7/tests$ ./cipher_comp && ./hash_comp > requested cipher CRYPTO_AES_CBC and mac CRYPTO_SHA1_HMAC, got cipher > cbc(aes) with driver cbc(aes-generic) and hash with driver > requested mac CRYPTO_SHA1, got hash sha1 with driver sha1-asm > > and loaded: > > fijam@yukikaze:~/cryptodev-linux-1.7/tests$ sudo modprobe mv_cesa > fijam@yukikaze:~/cryptodev-linux-1.7/tests$ ./cipher_comp && ./hash_comp > requested cipher CRYPTO_AES_CBC and mac CRYPTO_SHA1_HMAC, got cipher > cbc(aes) with driver mv-cbc-aes and hash with driver > requested mac CRYPTO_SHA1, got hash sha1 with driver sha1-asm > > They both pass, but note that even with mv_cesa loaded, sha1-asm is used. > > I checked /proc/crypto and mv_cesa has indeed the highest priority (300). I > tried to rmmod sha1_generic and sha1_arm but they just get loaded again.
This wouldn't work anyway since mv_cesa needs a software implementation to fall back to for odd cases. > I am not very familiar with kernel self-checks. I tested with the tcrypt > module (mode 200 for aes and mode 303 for sha) and I think I'm on the right > track: > > [227229.582143] alg: hash: Test 3 failed for mv-sha1 > [227229.586891] 00000000: 10 bf d7 00 71 0b bb 83 3a 26 d0 97 13 05 99 f5 > [227229.593454] 00000010: 3a 92 53 3c > [227229.597165] alg: hash: Test 1 failed for mv-hmac-sha1 > [227229.602343] 00000000: 0c aa 9f d5 37 c3 79 3a 91 d9 21 5f 42 2b 2c 24 > [227229.608906] 00000010: b7 c3 16 0c > [227251.303414] > [227251.303414] testing speed of sha1 > [227251.323114] test 0 ( 16 byte blocks, 16 bytes per update, 1 > updates): 518331 opers/sec, 8293296 bytes/sec > [and so on] > > It would appear that mv_sha1 fails, at which point the generic driver gets > loaded? > > Does it mean the kernel driver itself is at fault? Yes, indeed. I'm surprised it still turns up in /proc/crypto, but if the kernel self-test for a given crypto-provider fails it won't be used anymore (for good reason, of course). The driver failing with tcrypt is clear evidence of a driver problem and unrelated to cryptodev. Have a look at the kernel log, I bet there is output from the failing self-test at boot-time. Cheers, Phil _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
