qcrypto.txt 4.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145
  1. Introduction:
  2. =============
  3. Qualcomm Crypto (qcrypto) driver is a Linux crypto driver which interfaces
  4. with the Linux kernel crypto API layer to provide the HW crypto functions.
  5. This driver is accessed by kernel space apps via the kernel crypto API layer.
  6. At present there is no means for user space apps to access this module.
  7. Hardware description:
  8. =====================
  9. Qualcomm Crypto HW device family provides a series of algorithms implemented
  10. in the device.
  11. Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES
  12. algorithms, and concurrent operations of hashing, and ciphering.
  13. In addition to those functions provided by Crypto 2 HW, Crypto 3 provides fast
  14. AES algorithms.
  15. In addition to those functions provided by Crypto 3 HW, Crypto 3E provides
  16. HMAC-SHA1 hashing algorithm.
  17. In addition to those functions provided by Crypto 3 HW, Crypto 4.0 provides
  18. HMAC-SHA1/SHA256, AES CBC-MAC hashing algorithm and AES XTS/CCM cipher
  19. algorithms.
  20. Software description
  21. ====================
  22. The module init function (_qcrypto_init()), does a platform_register(),
  23. to register the driver. As the result, the driver probe function,
  24. _qcrypto_probe(), will be invoked for each registered device.
  25. In the probe function, driver opens the low level CE (qce_open), and
  26. registers the supported algorithms to the kernel crypto API layer.
  27. Currently, qcrypto supports the following algorithms.
  28. ablkcipher -
  29. cbc(aes),ecb(aes),ctr(aes)
  30. ahash -
  31. sha1, sha256
  32. aead -
  33. authenc(hmac(sha1),cbc(aes))
  34. The hmac(sha1), hmac(sha256, authenc(hmac(sha1),cbc(aes)), ccm(aes)
  35. and xts(aes) algorithms are registered for some platforms that
  36. support these in the CE hardware
  37. The HW device can support various algorithms. However, the most important
  38. algorithms to gain the performance using a HW crypto accelerator are
  39. AEAD, and ABLKCIPHER.
  40. AEAD stands for "authentication encryption with association data".
  41. ABLKCIPHER stands of "asynchronous block cipher".
  42. The AEAD structure is described in the following header file
  43. LINUX/opensource/kernel/include/crypto/aead.h
  44. The design of the driver is to allow multiple requests
  45. issued from kernel client SW (eg IPSec).
  46. Therefore, the driver will have to internally queue the requests, and
  47. serialize the requests to the low level qce driver.
  48. When a request is received from the client, if there is no outstanding
  49. request, a qce (or qce40) request is issued, otherwise, the request is
  50. queued in the driver queue.
  51. On completion of a request, the qce (or qce40) invokes the registered
  52. callback from the qcrypto. The internal tasklet (done_tasklet) is scheduled
  53. in this callback function. The sole purpose of done_tasklet is
  54. to call the completion of the current active request, and
  55. issue more requests to the qce (or qce40), if any exists.
  56. A spin lock is used to protect the critical section of internal queue to
  57. be accessed from multiple tasks, SMP, and completion callback
  58. from qce.
  59. The driver maintains a set of statistics using debug fs. The files are
  60. in /debug/qcrypto/stats1, /debug/qcrypto/stats2, /debug/qcrypto/stats3;
  61. one for each instance of device. Reading the file associated with
  62. a device will retrieve the driver statistics for that device.
  63. Any write to the file will clear the statistics.
  64. Test vectors for authenc(hmac(sha1),cbc(aes)) algorithm are
  65. developed offline, and imported to crypto/testmgr.c, and crypto/testmgr.h.
  66. Power Management
  67. ================
  68. none
  69. Interface:
  70. ==========
  71. The kernel interface is defined in
  72. LINUX/opensource/kernel/include/linux/crypto.h.
  73. Module parameters:
  74. ==================
  75. All the platform specific parameters are defined in the board init
  76. file, eg. arch/arm/mach-msm/board-mssm7x30.c for msm7x30.
  77. Dependencies:
  78. =============
  79. qce driver.
  80. User space utilities:
  81. =====================
  82. n/a
  83. Known issues:
  84. =============
  85. n/a
  86. To do:
  87. ======
  88. Add Hashing algorithms.
  89. Limitations:
  90. ===============
  91. (1) Each packet transfer size (for cipher and hash) is limited to maximum of
  92. 32KB. This is a limitation in the crypto engine hardware. Client will
  93. have to break packets larger than 32KB into multiple requests of smaller
  94. size data packets.
  95. (2) Do not load this driver if your device has user space apps that needs to
  96. access the crypto hardware. Please make sure to have the qcrypto module
  97. disabled/unloaded.
  98. Not having the driver loaded, will result in the kernel space apps to use
  99. the registered software implementation of the crypto algorithms.
  100. (3) If your device has Playready application enabled and uses the qcedev module
  101. to access the crypto hardware accelarator, please be informed that for
  102. performance reasons, the CE hardware will need to be dedicated to playready
  103. application. Any other user space or kernel application should be implemented
  104. to use the software implemenation of the crypto algorithms.
  105. (NOTE: Please refer to details on the limitations listed in qce/40.txt)