And looks like I have a typo in the flag! Duh! Thanks for getting me on the right track, rebuilding.
Cheers, Jan On Sat, May 30, 2015 at 1:57 PM, JM <fi...@archlinux.us> wrote: > Thanks for the quick reply. > > I did build with -DHAVE_CRYPTODEV -DUSE_CRYPTDEV_DIGESTS and the two > patches here: > http://rt.openssl.org/Ticket/Display.html?id=2770&user=guest&pass=guest > > OpenSSL version is 1.0.1k > > I tested ssh with a loopback scp like this: scp -c aes128-cbc > /media/ramdisk/data.bin fijam@localhost:/dev/null > > and it works great with mv_cesa/cryptodev. > > What I actually need is the hashing though... > > Best regards, > Jan > > > > On Sat, May 30, 2015 at 1:49 PM, Gordan Bobic <gor...@bobich.net> wrote: > >> Apologies if this is stated earlier in the thread, but you did build >> your OpenSSL with -DUSE_CRYPTODEV_DIGESTS, right? >> >> What version of OpenSSL are you using? Have you perchance checked >> whether sshd works with cryptodev offload (ssh -c aes128-cbc to your >> cryptodev machine)? >> >> Gordan >> >> >> On 30/05/15 12:43, JM wrote: >> >>> 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 >>> <mailto: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 <mailto: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 >>> >>> >> >> _______________________________________________ >> 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
