On 2015-05-28 11:00, Gordan Bobic wrote:
On 2015-05-27 23:33, Phil Sutter wrote:
On Wed, May 27, 2015 at 10:36:29PM +0100, Gordan Bobic wrote:
What do I need to change in which file to disable 0-copy?
Have a look at main.c, line 239:
| if (cop->flags & COP_FLAG_NO_ZC)
| ret = __crypto_run_std(ses_ptr, &kcop->cop);
| else
| ret = __crypto_run_zc(ses_ptr, kcop);
Changing the first line to 'if (1)' should suffice.
I did that and the problem persists:
# ./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
And ssh still fails with the same symptoms when using an
offloadable algorithm with cryptodev disabled.
Does that mean it is not a 0-copy related problem?
In fact, I can confirm the problem is not at all related to mv_cesa.
I just unloaded the mv_cesa driver which means that with cryptodev
it will be the kernel doing the AES using the generic kernel
driver. And ssh still fails with that when an offloadable algorithm
is being used. So the problem is almost certainly somewhere in the
OpenSSL <-> cryptodev interaction.
Gordan
_______________________________________________
Cryptodev-linux-devel mailing list
Cryptodev-linux-devel@gna.org
https://mail.gna.org/listinfo/cryptodev-linux-devel
