On 2015-05-27 20:34, Phil Sutter wrote:
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?
I assumed so. It hadn't occurred to me it might not.
> 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.).
I'll see if I can get the latest mv_cesa module to build/work.
> 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.
Changing the cryptodev code sounds like the way forward for the test
purposes at least, mainly because rebuilding cryptodev takes a minute
or so, and rebuilding the OpenSSL package takes a couple of hours.
What do I need to change in which file to disable 0-copy?
Gordan
_______________________________________________
Cryptodev-linux-devel mailing list
Cryptodev-linux-devel@gna.org
https://mail.gna.org/listinfo/cryptodev-linux-devel
