• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 98 subscribers
  • Views 3490 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x hardware crypto failures with cryptodev

Andrew Goodbody
Prodigy 140 points
Other Parts Discussed in Thread: AM3352

I am trying to use cryptodev on the AM3352 using kernel 3.14.26 as in the latest EZSDK.

I am getting failures from the cryptodev self tests that suggest problems in the kernel drivers.

Can anyone confirm successful use of the hardware crypto and in particular successful passing of the cryptodev tests?

The failures I get are as follows, all other tests pass.

# ./cipher-aead-srtp
ioctl(CIOCAUTHCRYPT): Invalid argument

# ./cipher-gcm
test_crypto: 119
ioctl(CIOCGSESSION): Invalid argument

# ./cipher_comp
requested cipher CRYPTO_AES_CBC and mac CRYPTO_SHA1_HMAC, got cipher cbc(aes) with driver cbc-aes-omap and hash  with driver
fail for datalen 16, IVs do not match!
test_crypto() failed for datalen of 16

# ./hmac_comp
requested cipher CRYPTO_AES_CBC and mac CRYPTO_SHA1_HMAC, got cipher cbc(aes) with driver cbc-aes-omap and hash hmac(sha1) with driver omap-hmac-sha1
fail for datalen 16, updated IVs do not match!
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

  • 0 in reply to Biser Gatchev-XID
    Prodigy 140 points
    Thanks, I am familiar with that page. I do have the openssl speed tests working and can see the improvement from using cryptodev with the hardware accelerator. The problems I am having are with the cryptodev self tests that are showing failures.
  • 0 in reply to Andrew Goodbody
    TI__Guru**** 393215 points

    I have asked for assistance from a crypto expert on this.

  • 0
    TI__Guru** 116170 points

    Hi Andrew,

    The issue with AES_CBC and SHA1_HMAC seems to be similar to the issue that was reported on 3.14.26 kernel and OpenSSL 1.0.1j with cryptodev-linux here:

    The issue with TI SHAM driver that was reported with 3.14.26 kernel and OpenSSL has now been resolved in the latest TI Linux 3.14 build. You can download the latest 3.14 tag 3.14.39 -5c43c53 tag from git.ti.com and let us know if you still see this issue.

    AES GCM cipher wasn`t supported in the driver until recently but there have been new patches added to the 3.14 kernel where this feature should be enabled. The commit id where I see the fix is 5089d1c.  You can check the details of all the patches in the log from May 11th , in the link provided below:

    https://git.ti.com/ti-linux-kernel/ti-linux-kernel/commits/ti-linux-3.14.y?page=6

    Hope this resolves this issue. I will try to reproduce this with my setup and let you know if I see the same issues.


    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 140 points

    Thanks I will have to check that out which will take me a little while. I have been using the kernel from git.ti.com/sitara-linux/sitara-linux.git so I did not see those updates.


    Andrew

  • 0 in reply to Rahul Prabhu
    Prodigy 140 points

    I have now built a new updated kernel and I am still seeing the same tests fail, although some have changed errors. In addition the gcm test now gives the result below.

    # ./cipher-gcm
    [  283.112585] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.119608] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.126592] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.133573] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.140554] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.147534] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.154513] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.161492] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.168471] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.175449] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.182429] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.189408] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.196386] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.203439] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.210426] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.217436] omap-aes 53500000.aes: GCM decryption: Tag Message is wrong
    [  283.232439] cryptodev: cipher-gcm[261] (waitfor:271): error from async request: -74
    [  283.240553] cryptodev: cipher-gcm[261] (auth_n_crypt:602): cryptodev_cipher_decrypt: -74
    test_encrypt_decrypt: 293
    ioctl(CIOCAUTHCRYPT): Bad message

    The commit you referenced above, 5089d1c, is actually overwritten by a merge later the same day. However that commit was only adding a 2nd instance of the AES accelerator in the device tree for DRA7. I believe that there is a 2nd instance in the AM335x as well, so should I add a 2nd instance to the device tree? If so do you have the details for what is needed there? Is that going to make any difference to the above failures or will it just improve the performance?


    Thanks,

    Andrew

  • 0 in reply to Rahul Prabhu
    Prodigy 140 points

    Hi,


    I was just wondering if you had managed to reproduce my results or if there was any other news?


    Thanks,

    Andrew

  • 0
    TI__Guru**** 167581 points

    Andrew,

    I am not sure how much I will trust the test applications provided in the cryptodev package. For example,

    Andrew Goodbody said:
    # ./cipher-aead-srtp
    ioctl(CIOCAUTHCRYPT): Invalid argument

    this failure is due to cipher-aead-srtp sends 1021 bytes to the cryptodev driver for operation, but ctr(aes) cipher requires the data has to be 16 bytes aligned, so the test failed. If running the similar test using openssl, openssl will by default pads the data to 1024 bytes before sending it to cryptodev driver.

  • 0 in reply to Bin Liu
    Prodigy 140 points
    I don't think that is correct. Alignment only refers to the start of the data.
    www.cryptopp.com/.../CTR_Mode has the quote "The mode does not require padding the plain text to the block size of the cipher."
    Also reading the referenced standard at csrc.nist.gov/.../sp800-38a.pdf in section 6.5 there is the quote "For the last block, which may be a partial block of u bits, the most significant u bits of the last output block are used for the exclusive-OR operation;"
    So you should be able to supply an incomplete last block without padding.
  • 0 in reply to Andrew Goodbody
    Prodigy 140 points

    Is there any news about this?