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
[email protected]
https://mail.gna.org/listinfo/cryptodev-linux-devel
