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