Hello,
I am currently porting cryptodev linux to my embedded linux distribution (based on µClinux) and I am experiencing some issues with what appears to be the data transferred to the SHA1 driver written for my platform. Indeed, my processor (Freescale Kinetis ARM Cortex-M4) features a cryptographic acceleration unit for which I have developed a driver. The driver I have written for my cryptographic acceleration unit is inspired on the mcfcau driver present in the OpenWrt distribution which I modified to provide the assembly code (provided by Freescale) for my cryptographic acceleration unit (MMCAU). That drivers gets consistently loaded and tested (using tcrypt) during the boot phase. However, while running the tests provided by cryptodev Linux, I have experienced puzzling behaviors for the debugging of which I am not sure how I shall proceed. Using the custom debugging messages of my SHA1 driver, which allow me to validate the data being handle inside of it, I can observe that the data being transferred to it do not seem to be correct. I can indeed suppose that my driver is a stake here, however, I am not sure how to proceed to validate and find out the issue since I have to use cryptodev to interact with it. Here is some specific information: My drivers works 100% of the time with the tcrypt tests. I have added the correct (so I think) Makefile and Kconfig file so that I can build cryptodev as a builtin module in my µClinux distribution. The only file I have modified is ioctl.c so I can add some flags coming from menuconfig in order to assign the cryptodev_verbosity variable to the right value depending on my Kconfig settings. The lines in proc/crypto related to the SHA1 driver are Name : sha1 Driver : sha1-kinetis-mmcau Module : kernel Priority : 300 Refcnt : 1 Selftest : passed Type : shash Blocksize : 64 Digestsize : 20 The different steps of my driver access related to the HASH test 1 test present in hmac.c are illustrated hereunder (the driver works with a 512 bits buffer which gets filled through the update sequence until the point it is full. When it is full, it gets passed on to the coprocessor which performs that hash). Before I detail the different steps, a few observations first: The issue seems that some bytes seem to be losts when the data is passed to my SHA1 driver: - The correct ASCII code for the transferred message should be: 77 68 61 74 20 64 6F 20 79 61 20 77 61 6E 74 20 66 6f 72 20 6E 6F 74 68 69 6E 67 3F. - The actual message getting transferred has the following code 77 64 6F 20 79 61 20 77 61 6E 74 20 66 6F 72 20 6E 6F 74 68 69 6E 67 3F 00 69 6F 63 as if a few bytes where lost after the 1st one Another thing that gets me worried is that the message is actually transferred to my driver in 3 pieces: - 1st piece is 1 byte long - 2nd piece is 0 byte long - 3rd piece is 27 bytes long and contains the end of the message. SHA1 init - Initial state is: Count is 0 State val 0 is 67452301 State val 1 is EFCDAB89 State val 2 is 98BADCFE State val 3 is 10325476 State val 4 is C3D2E1F0 Buffer is : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SHA1 update data len: 1 Source Data: 77 Final step: update buffer Partial index in buffer 0 Num data to transfer 1 Data to be transfered: 77 Buffer Content: 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SHA1 update data len: 0 Source Data: Final step: update buffer Partial index in buffer 1 Num data to transfer 0 Data to be transfered: Buffer Content: 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SHA1 update data len: 27 Source Data: 64 6F 20 79 61 20 77 61 6E 74 20 66 6F 72 20 6E 6F 74 68 69 6E 67 3F 00 69 6F 63 Final step: update buffer Partial index in buffer 1 Num data to transfer 27 Data to be transfered: 64 6F 20 79 61 20 77 61 6E 74 20 66 6F 72 20 6E 6F 74 68 69 6E 67 3F 00 69 6F 63 Buffer Content: 77 64 6F 20 79 61 20 77 61 6E 74 20 66 6F 72 20 6E 6F 74 68 69 6E 67 3F 00 69 6F 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SHA1 Final - Padding Padding length is 28 Padding data is : 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SHA1 update data len: 28 Source Data: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Final step: update buffer Partial index in buffer 28 Num data to transfer 28 Data to be transfered: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Buffer Content: 77 64 6F 20 79 61 20 77 61 6E 74 20 66 6F 72 20 6E 6F 74 68 69 6E 67 3F 00 69 6F 63 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SHA1 Final - Adding length (in bits) Adding global length 224 SHA1 update data len: 8 Source Data: 00 00 00 00 00 00 00 E0 Partial = 56: updating buffer New buffer content is : 77 64 6F 20 79 61 20 77 61 6E 74 20 66 6F 72 20 6E 6F 74 68 69 6E 67 3F 00 69 6F 63 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E0 Computation - Before Final step: update buffer Partial index in buffer 0 Num data to transfer 0 Data to be transfered: Buffer Content: 00 00 00 00 00 00 00c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 SHA1 Final - Extracting state Signature is : Data 0 is 15DA2E75 Data 1 is FA20B98B Data 2 is F22EB348 Data 3 is F13ECB9E Data 4 is 56D7A33E CRYPTO_SHA1, got sha1 with driver sha1-kinetis-mmcau mac: 752eda158bb920fa48b32ef29ecb3ef13ea3d756 Thank you in advance for any insight you might provide. Best regards, François
_______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel