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
