Hello again, I have updated the kernel on the affected machine to 4.0.4 and now mv_cesa successfully passes self checks. I rebuilt the cryptodev-linux module with the compilation fix from git and the tests included in cryptodev also pass now.
However, I am having trouble doing sha1 hashing using mv_cesa through cryptodev from other applications, while aes-128-cbc works correctly. Tested with openssl (built with the recommended patches and flags): AES: openssl speed aes-128-cbc -elapsed software path is taken openssl speed -evp aes-128-cbc -elapsed offloading works correctly, and I see mv_crypto taking CPU time SHA1: openssl speed sha1 -elapsed software path is taken openssl speed -evp sha1 -elapsed software path is taken, no difference in speed, mv_crypto at 0% CPU time this is what I get in dmesg with verbosity set to 3: -evp aes: http://pastebin.com/K3TaJ2S8 -evp sha1: http://pastebin.com/udK6EYwS In /proc/crypto I have name : sha1 driver : mv-sha1 module : mv_cesa priority : 300 refcnt : 1 selftest : passed type : ahash async : yes blocksize : 64 digestsize : 20 which is the highest priority for sha1 that I have in this system. Importantly, ./sha_speed from cryptodev-linux/tests correctly requests mv-sha1 and I can see it use mv_crypto in the process list with about 45% cpu usage. To summarize, openssl can use mv_cesa through cryptodev only for aes-128-cbc and not for sha1, even though tests included in cryptodev can use mv_cesa for both aes and sha1. Can someone shed any light on that? Best regards, Jan On Mon, Apr 27, 2015 at 2:24 PM, Phil Sutter <p...@nwl.cc> wrote: > 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 >
_______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
