Re: [Cryptodev-linux-devel] Problem with OpenSSH/OpenSSL Interaction When Cryptodev is Used
On 2015-05-27 11:07, Phil Sutter wrote: Hi, On Wed, May 27, 2015 at 10:25:00AM +0100, Gordan Bobic wrote: ./cipher-aead-srtp ioctl(CIOCGSESSION): Invalid argument Not sure if this should succeed at all, at least that's not my code. ;) # ./hmac_comp requested cipher CRYPTO_AES_CBC and mac CRYPTO_SHA1_HMAC, got cipher cbc(aes) with driver mv-cbc-aes and hash hmac(sha1) with driver mv-hmac-sha1 fail for datalen 0x10, MACs do not match! wrong mac: \xd7\xd1\xa6\xef\x0a\x38\xe1\x09\x45\xe1\x8b\x48\x88\xaa\xa9\x23\x4c\xd4\x67\xd1 right mac: \xd7\xd1\xa6\xef\x0a\x38\xe1\x09\x45\xe1\x8b\x48\x88\xaa\xa9\x23\x4c\xd4\x67\xd1 test_crypto() failed for datalen of 16 That's bad. I'm pretty sure SSH uses HMAC. Unless there is a bug in hmac_comp, the fact that identical binary strings are shown for actual and expected result makes me suspect a caching issue (the additional data access while printing sometimes leads to a cache flush so one does not see the complained difference). But - my OpenSSL is built without -DUSE_CRYPTODEV_DIGESTS, so if OpenSSH used OpenSSL for that, there should be no attempt to even use hardware digests. You are using MV_CESA, therefore you are probably on a Kirkwood with VIVT cache architecture - which is pretty delicate when it comes to the zero-copy stuff involved. Please make sure your kernel doesn't miss any fixes in mv_cesa regarding cache flushes. That is easier said than done. I'm using the upstream vendor provided sources that are both ancient (3.4.6) and heavily patched (the diff between mainline 3.4.6 and their kernel is MBs). Also, for the sake of testing you could turn off zero-copy in cryptodev as well. How? I don't see any obvious options in the Makefile to do that. All I see is the async option, which is disabled by default. Gordan ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
Re: [Cryptodev-linux-devel] Problem with OpenSSH/OpenSSL Interaction When Cryptodev is Used
On 2015-05-27 01:08, Phil Sutter wrote: Hi, On Tue, May 26, 2015 at 07:29:34PM +0100, Gordan Bobic wrote: A bit of extra info, with cryptodev_verbosity=2, on 0.9 when the error occurs: cryptodev: sshd[1205]: invalid session ID=0xAADBA6A0 With 1.7: cryptodev: sshd[1520] (fill_kcop_from_cop:647): invalid session ID=0xEC91F39A cryptodev: sshd[1520] (cryptodev_ioctl:857): Error copying from user But the test code (i.e. the various *_comp programs) succeeds? Thank you for that hint: # cd tests # make ./cipher ./hmac ./async_cipher ./async_hmac ./cipher-aead-srtp ioctl(CIOCGSESSION): Invalid argument make: *** [check] Error 1 In dmesg: cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at 80f553e0 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd0180 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd06c0 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd0e40 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd0780 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd0b40 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd03c0 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at b4db8b00 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at b4db8ec0 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at b4db82c0 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at b4db8a40 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd0840 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd0600 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd0480 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd0240 cryptodev: cipher[13263] (cryptodev_open:480): allocated new item at a2bd0c00 cryptodev: cipher[13263] (cryptodev_open:485): Cryptodev handle initialised, 16 elements in queue cryptodev: cipher[13263] (crypto_create_session:284): got alignmask 0 cryptodev: cipher[13263] (crypto_create_session:287): preallocating for 32 user pages cryptodev: cipher[13263] (crypto_create_session:284): got alignmask 0 cryptodev: cipher[13263] (crypto_create_session:287): preallocating for 32 user pages cryptodev: cipher[13263] (crypto_destroy_session:341): Removed session 0xB286F3D7 cryptodev: cipher[13263] (crypto_destroy_session:344): freeing space for 32 user pages cryptodev: cipher[13263] (crypto_create_session:284): got alignmask 0 cryptodev: cipher[13263] (crypto_create_session:287): preallocating for 32 user pages cryptodev: cipher[13263] (crypto_destroy_session:341): Removed session 0x781F7717 cryptodev: cipher[13263] (crypto_destroy_session:344): freeing space for 32 user pages cryptodev: cipher[13263] (crypto_create_session:284): got alignmask 0 cryptodev: cipher[13263] (crypto_create_session:287): preallocating for 32 user pages cryptodev: cipher[13263] (crypto_destroy_session:341): Removed session 0x89FD4E64 cryptodev: cipher[13263] (crypto_destroy_session:344): freeing space for 32 user pages cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd0c00 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd0240 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd0480 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd0600 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd0840 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at b4db8a40 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at b4db82c0 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at b4db8ec0 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at b4db8b00 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd03c0 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd0b40 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd0780 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd0e40 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd06c0 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at a2bd0180 cryptodev: cipher[13263] (cryptodev_release:519): freeing item at 80f553e0 cryptodev: cipher[13263] (crypto_destroy_session:341): Removed session 0x8AD52BF7 cryptodev: cipher[13263] (crypto_destroy_session:344): freeing space for 32 user pages cryptodev: cipher[13263] (cryptodev_release:541): Cryptodev handle deinitialised, 16 elements freed cryptodev: hmac[13264] (cryptodev_open:480): allocated new item at a2bd09c0 cryptodev: hmac[13264] (cryptodev_open:480): allocated new item at a2bd00c0 cryptodev: hmac[13264] (cryptodev_open:480): allocated new item at 80f553e0 cryptodev: hmac[13264] (cryptodev_open:480): allocated new item at a2bd0180 cryptodev: hmac[13264] (cryptodev_open:480):
Re: [Cryptodev-linux-devel] Problem with OpenSSH/OpenSSL Interaction When Cryptodev is Used
On Wed, May 27, 2015 at 11:20:28AM +0100, Gordan Bobic wrote: On 2015-05-27 11:07, Phil Sutter wrote: Hi, On Wed, May 27, 2015 at 10:25:00AM +0100, Gordan Bobic wrote: ./cipher-aead-srtp ioctl(CIOCGSESSION): Invalid argument Not sure if this should succeed at all, at least that's not my code. ;) # ./hmac_comp requested cipher CRYPTO_AES_CBC and mac CRYPTO_SHA1_HMAC, got cipher cbc(aes) with driver mv-cbc-aes and hash hmac(sha1) with driver mv-hmac-sha1 fail for datalen 0x10, MACs do not match! wrong mac: \xd7\xd1\xa6\xef\x0a\x38\xe1\x09\x45\xe1\x8b\x48\x88\xaa\xa9\x23\x4c\xd4\x67\xd1 right mac: \xd7\xd1\xa6\xef\x0a\x38\xe1\x09\x45\xe1\x8b\x48\x88\xaa\xa9\x23\x4c\xd4\x67\xd1 test_crypto() failed for datalen of 16 That's bad. I'm pretty sure SSH uses HMAC. Unless there is a bug in hmac_comp, the fact that identical binary strings are shown for actual and expected result makes me suspect a caching issue (the additional data access while printing sometimes leads to a cache flush so one does not see the complained difference). But - my OpenSSL is built without -DUSE_CRYPTODEV_DIGESTS, so if OpenSSH used OpenSSL for that, there should be no attempt to even use hardware digests. Does this cover HMAC as well? You are using MV_CESA, therefore you are probably on a Kirkwood with VIVT cache architecture - which is pretty delicate when it comes to the zero-copy stuff involved. Please make sure your kernel doesn't miss any fixes in mv_cesa regarding cache flushes. That is easier said than done. I'm using the upstream vendor provided sources that are both ancient (3.4.6) and heavily patched (the diff between mainline 3.4.6 and their kernel is MBs). Sounds familiar. For mv_cesa though, it should be possible to just take over mainline mv_cesa.c with minimal adjustments (drop clock gating e.g.). Also, for the sake of testing you could turn off zero-copy in cryptodev as well. How? I don't see any obvious options in the Makefile to do that. All I see is the async option, which is disabled by default. You can set COP_FLAG_NO_ZC in struct crypt_op. So you need to recompile openssl. Alternatively you could change the code in cryptodev referring to that flag so it always behaves as if it had been set. Cheers, Phil ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
