9 years, 6 months ago.

Issue with md_wrap when integrating a hardware acceleration unit

Hello,

I am working on the integration of the MMCAU unit of my Freescale Kinetis device with mbed TLS. I am working with µCLinux as an OS and have successfully ported the mbed TLS library on my platform while I run the "default" software implementation (all tests successfull). In order to benefit from the presence of the the MMCAU unit on my processor, I have developped an ioctl driver that is getting called for the des, aes, md5, sha1 and sha256 function through the usage of the des_alt.c, aes_alt.c, md5_alt.c, ... files.

In order to intialize the grant access to the MMCAU unit through my driver, when initializing the context of the algorithm, I open the "/dev/mmcau" device and allocate a "cfd" variable which now belongs to my context, the I send an initialization command telling the driver which algorithm(s) shall be supported. This is successfully working for the great majority of the cases (I can run almost all mbed TLS tests successfully) and I can see a signficant performance improvement (i.e. about 50% less time on the encryption of a large (4M byte) file using aescrypt2).

However, this scheme seem to cause a problem with the md_wrap infrastructure for the digest/hash functions. Indeed it seems that the md_wrap related infrastructure (I will use that term since I do not see any more appropriate term) does not perform the context initialization and release operations. For example, I cannot see the md5_init and md5_free functions being called. This is really frustrating since this means that the porting of the digest and hash functions I did will probably not work for SSL/TLS.

I tried to modify md_wrap.c and add some rules (#if defined(POLARSSL_MD5_ALT)) to force the initalization (in the function md5_ctx_alloc) and release (in the function md5_ctx_free) but some of the test did not pass since it seems that these functions are not always called by the tests.

Then I tried to port this context initialization to md5_(hmac_)update_wrap and md5_(hmac_)finish_wrap but no luck either since it seems that sometimes, start is called without the corresponding finish (for example in the test "generic multi step md5 Test vector RFC1321 #X). This is really sad since, in order to limit the kernel memory allocation achieved by my driver, I try to limit the number of times the driver can be opened without the subsequent close.

Indications on how to fix this would be really appreciated.