]>
Commit | Line | Data |
---|---|---|
9f95a23c TL |
1 | /* SPDX-License-Identifier: BSD-3-Clause |
2 | * Copyright(c) 2016-2019 Intel Corporation | |
7c673cae FG |
3 | */ |
4 | ||
5 | #ifndef _RTE_CRYPTO_SYM_H_ | |
6 | #define _RTE_CRYPTO_SYM_H_ | |
7 | ||
8 | /** | |
9 | * @file rte_crypto_sym.h | |
10 | * | |
11 | * RTE Definitions for Symmetric Cryptography | |
12 | * | |
13 | * Defines symmetric cipher and authentication algorithms and modes, as well | |
14 | * as supported symmetric crypto operation combinations. | |
15 | */ | |
16 | ||
17 | #ifdef __cplusplus | |
18 | extern "C" { | |
19 | #endif | |
20 | ||
21 | #include <string.h> | |
22 | ||
23 | #include <rte_mbuf.h> | |
24 | #include <rte_memory.h> | |
25 | #include <rte_mempool.h> | |
26 | #include <rte_common.h> | |
27 | ||
28 | ||
29 | /** Symmetric Cipher Algorithms */ | |
30 | enum rte_crypto_cipher_algorithm { | |
31 | RTE_CRYPTO_CIPHER_NULL = 1, | |
32 | /**< NULL cipher algorithm. No mode applies to the NULL algorithm. */ | |
33 | ||
34 | RTE_CRYPTO_CIPHER_3DES_CBC, | |
35 | /**< Triple DES algorithm in CBC mode */ | |
36 | RTE_CRYPTO_CIPHER_3DES_CTR, | |
37 | /**< Triple DES algorithm in CTR mode */ | |
38 | RTE_CRYPTO_CIPHER_3DES_ECB, | |
39 | /**< Triple DES algorithm in ECB mode */ | |
40 | ||
41 | RTE_CRYPTO_CIPHER_AES_CBC, | |
42 | /**< AES algorithm in CBC mode */ | |
7c673cae FG |
43 | RTE_CRYPTO_CIPHER_AES_CTR, |
44 | /**< AES algorithm in Counter mode */ | |
45 | RTE_CRYPTO_CIPHER_AES_ECB, | |
46 | /**< AES algorithm in ECB mode */ | |
47 | RTE_CRYPTO_CIPHER_AES_F8, | |
48 | /**< AES algorithm in F8 mode */ | |
7c673cae FG |
49 | RTE_CRYPTO_CIPHER_AES_XTS, |
50 | /**< AES algorithm in XTS mode */ | |
51 | ||
52 | RTE_CRYPTO_CIPHER_ARC4, | |
53 | /**< (A)RC4 cipher algorithm */ | |
54 | ||
55 | RTE_CRYPTO_CIPHER_KASUMI_F8, | |
56 | /**< KASUMI algorithm in F8 mode */ | |
57 | ||
58 | RTE_CRYPTO_CIPHER_SNOW3G_UEA2, | |
59 | /**< SNOW 3G algorithm in UEA2 mode */ | |
60 | ||
61 | RTE_CRYPTO_CIPHER_ZUC_EEA3, | |
62 | /**< ZUC algorithm in EEA3 mode */ | |
63 | ||
11fdf7f2 TL |
64 | RTE_CRYPTO_CIPHER_DES_CBC, |
65 | /**< DES algorithm in CBC mode */ | |
66 | ||
67 | RTE_CRYPTO_CIPHER_AES_DOCSISBPI, | |
68 | /**< AES algorithm using modes required by | |
69 | * DOCSIS Baseline Privacy Plus Spec. | |
70 | * Chained mbufs are not supported in this mode, i.e. rte_mbuf.next | |
71 | * for m_src and m_dst in the rte_crypto_sym_op must be NULL. | |
72 | */ | |
73 | ||
74 | RTE_CRYPTO_CIPHER_DES_DOCSISBPI, | |
75 | /**< DES algorithm using modes required by | |
76 | * DOCSIS Baseline Privacy Plus Spec. | |
77 | * Chained mbufs are not supported in this mode, i.e. rte_mbuf.next | |
78 | * for m_src and m_dst in the rte_crypto_sym_op must be NULL. | |
79 | */ | |
80 | ||
7c673cae | 81 | RTE_CRYPTO_CIPHER_LIST_END |
11fdf7f2 | 82 | |
7c673cae FG |
83 | }; |
84 | ||
11fdf7f2 TL |
85 | /** Cipher algorithm name strings */ |
86 | extern const char * | |
87 | rte_crypto_cipher_algorithm_strings[]; | |
88 | ||
7c673cae FG |
89 | /** Symmetric Cipher Direction */ |
90 | enum rte_crypto_cipher_operation { | |
91 | RTE_CRYPTO_CIPHER_OP_ENCRYPT, | |
92 | /**< Encrypt cipher operation */ | |
93 | RTE_CRYPTO_CIPHER_OP_DECRYPT | |
94 | /**< Decrypt cipher operation */ | |
95 | }; | |
96 | ||
11fdf7f2 TL |
97 | /** Cipher operation name strings */ |
98 | extern const char * | |
99 | rte_crypto_cipher_operation_strings[]; | |
100 | ||
7c673cae FG |
101 | /** |
102 | * Symmetric Cipher Setup Data. | |
103 | * | |
104 | * This structure contains data relating to Cipher (Encryption and Decryption) | |
105 | * use to create a session. | |
106 | */ | |
107 | struct rte_crypto_cipher_xform { | |
108 | enum rte_crypto_cipher_operation op; | |
109 | /**< This parameter determines if the cipher operation is an encrypt or | |
110 | * a decrypt operation. For the RC4 algorithm and the F8/CTR modes, | |
111 | * only encrypt operations are valid. | |
112 | */ | |
113 | enum rte_crypto_cipher_algorithm algo; | |
114 | /**< Cipher algorithm */ | |
115 | ||
116 | struct { | |
117 | uint8_t *data; /**< pointer to key data */ | |
9f95a23c | 118 | uint16_t length;/**< key length in bytes */ |
7c673cae FG |
119 | } key; |
120 | /**< Cipher key | |
121 | * | |
122 | * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data will | |
123 | * point to a concatenation of the AES encryption key followed by a | |
124 | * keymask. As per RFC3711, the keymask should be padded with trailing | |
125 | * bytes to match the length of the encryption key used. | |
126 | * | |
7c673cae FG |
127 | * Cipher key length is in bytes. For AES it can be 128 bits (16 bytes), |
128 | * 192 bits (24 bytes) or 256 bits (32 bytes). | |
129 | * | |
7c673cae FG |
130 | * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.length |
131 | * should be set to the combined length of the encryption key and the | |
132 | * keymask. Since the keymask and the encryption key are the same size, | |
133 | * key.length should be set to 2 x the AES encryption key length. | |
134 | * | |
135 | * For the AES-XTS mode of operation: | |
136 | * - Two keys must be provided and key.length refers to total length of | |
137 | * the two keys. | |
9f95a23c TL |
138 | * - key.data must point to the two keys concatenated together |
139 | * (key1 || key2). | |
7c673cae FG |
140 | * - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes). |
141 | * - Both keys must have the same size. | |
142 | **/ | |
9f95a23c TL |
143 | struct { |
144 | uint16_t offset; | |
145 | /**< Starting point for Initialisation Vector or Counter, | |
146 | * specified as number of bytes from start of crypto | |
147 | * operation (rte_crypto_op). | |
148 | * | |
149 | * - For block ciphers in CBC or F8 mode, or for KASUMI | |
150 | * in F8 mode, or for SNOW 3G in UEA2 mode, this is the | |
151 | * Initialisation Vector (IV) value. | |
152 | * | |
153 | * - For block ciphers in CTR mode, this is the counter. | |
154 | * | |
155 | * - For GCM mode, this is either the IV (if the length | |
156 | * is 96 bits) or J0 (for other sizes), where J0 is as | |
157 | * defined by NIST SP800-38D. Regardless of the IV | |
158 | * length, a full 16 bytes needs to be allocated. | |
159 | * | |
160 | * - For CCM mode, the first byte is reserved, and the | |
161 | * nonce should be written starting at &iv[1] (to allow | |
162 | * space for the implementation to write in the flags | |
163 | * in the first byte). Note that a full 16 bytes should | |
164 | * be allocated, even though the length field will | |
165 | * have a value less than this. Note that the PMDs may | |
166 | * modify the memory reserved (the first byte and the | |
167 | * final padding) | |
168 | * | |
169 | * - For AES-XTS, this is the 128bit tweak, i, from | |
170 | * IEEE Std 1619-2007. | |
171 | * | |
172 | * For optimum performance, the data pointed to SHOULD | |
173 | * be 8-byte aligned. | |
174 | */ | |
175 | uint16_t length; | |
176 | /**< Length of valid IV data. | |
177 | * | |
178 | * - For block ciphers in CBC or F8 mode, or for KASUMI | |
179 | * in F8 mode, or for SNOW 3G in UEA2 mode, this is the | |
180 | * length of the IV (which must be the same as the | |
181 | * block length of the cipher). | |
182 | * | |
183 | * - For block ciphers in CTR mode, this is the length | |
184 | * of the counter (which must be the same as the block | |
185 | * length of the cipher). | |
186 | * | |
187 | * - For GCM mode, this is either 12 (for 96-bit IVs) | |
188 | * or 16, in which case data points to J0. | |
189 | * | |
190 | * - For CCM mode, this is the length of the nonce, | |
191 | * which can be in the range 7 to 13 inclusive. | |
192 | */ | |
193 | } iv; /**< Initialisation vector parameters */ | |
7c673cae FG |
194 | }; |
195 | ||
196 | /** Symmetric Authentication / Hash Algorithms */ | |
197 | enum rte_crypto_auth_algorithm { | |
198 | RTE_CRYPTO_AUTH_NULL = 1, | |
199 | /**< NULL hash algorithm. */ | |
200 | ||
201 | RTE_CRYPTO_AUTH_AES_CBC_MAC, | |
202 | /**< AES-CBC-MAC algorithm. Only 128-bit keys are supported. */ | |
7c673cae FG |
203 | RTE_CRYPTO_AUTH_AES_CMAC, |
204 | /**< AES CMAC algorithm. */ | |
7c673cae | 205 | RTE_CRYPTO_AUTH_AES_GMAC, |
9f95a23c | 206 | /**< AES GMAC algorithm. */ |
7c673cae FG |
207 | RTE_CRYPTO_AUTH_AES_XCBC_MAC, |
208 | /**< AES XCBC algorithm. */ | |
209 | ||
210 | RTE_CRYPTO_AUTH_KASUMI_F9, | |
211 | /**< KASUMI algorithm in F9 mode. */ | |
212 | ||
213 | RTE_CRYPTO_AUTH_MD5, | |
214 | /**< MD5 algorithm */ | |
215 | RTE_CRYPTO_AUTH_MD5_HMAC, | |
216 | /**< HMAC using MD5 algorithm */ | |
217 | ||
218 | RTE_CRYPTO_AUTH_SHA1, | |
219 | /**< 128 bit SHA algorithm. */ | |
220 | RTE_CRYPTO_AUTH_SHA1_HMAC, | |
221 | /**< HMAC using 128 bit SHA algorithm. */ | |
222 | RTE_CRYPTO_AUTH_SHA224, | |
223 | /**< 224 bit SHA algorithm. */ | |
224 | RTE_CRYPTO_AUTH_SHA224_HMAC, | |
225 | /**< HMAC using 224 bit SHA algorithm. */ | |
226 | RTE_CRYPTO_AUTH_SHA256, | |
227 | /**< 256 bit SHA algorithm. */ | |
228 | RTE_CRYPTO_AUTH_SHA256_HMAC, | |
229 | /**< HMAC using 256 bit SHA algorithm. */ | |
230 | RTE_CRYPTO_AUTH_SHA384, | |
231 | /**< 384 bit SHA algorithm. */ | |
232 | RTE_CRYPTO_AUTH_SHA384_HMAC, | |
233 | /**< HMAC using 384 bit SHA algorithm. */ | |
234 | RTE_CRYPTO_AUTH_SHA512, | |
235 | /**< 512 bit SHA algorithm. */ | |
236 | RTE_CRYPTO_AUTH_SHA512_HMAC, | |
237 | /**< HMAC using 512 bit SHA algorithm. */ | |
238 | ||
239 | RTE_CRYPTO_AUTH_SNOW3G_UIA2, | |
240 | /**< SNOW 3G algorithm in UIA2 mode. */ | |
241 | ||
242 | RTE_CRYPTO_AUTH_ZUC_EIA3, | |
243 | /**< ZUC algorithm in EIA3 mode */ | |
244 | ||
9f95a23c TL |
245 | RTE_CRYPTO_AUTH_SHA3_224, |
246 | /**< 224 bit SHA3 algorithm. */ | |
247 | RTE_CRYPTO_AUTH_SHA3_224_HMAC, | |
248 | /**< HMAC using 224 bit SHA3 algorithm. */ | |
249 | RTE_CRYPTO_AUTH_SHA3_256, | |
250 | /**< 256 bit SHA3 algorithm. */ | |
251 | RTE_CRYPTO_AUTH_SHA3_256_HMAC, | |
252 | /**< HMAC using 256 bit SHA3 algorithm. */ | |
253 | RTE_CRYPTO_AUTH_SHA3_384, | |
254 | /**< 384 bit SHA3 algorithm. */ | |
255 | RTE_CRYPTO_AUTH_SHA3_384_HMAC, | |
256 | /**< HMAC using 384 bit SHA3 algorithm. */ | |
257 | RTE_CRYPTO_AUTH_SHA3_512, | |
258 | /**< 512 bit SHA3 algorithm. */ | |
259 | RTE_CRYPTO_AUTH_SHA3_512_HMAC, | |
260 | /**< HMAC using 512 bit SHA3 algorithm. */ | |
261 | ||
7c673cae FG |
262 | RTE_CRYPTO_AUTH_LIST_END |
263 | }; | |
264 | ||
11fdf7f2 TL |
265 | /** Authentication algorithm name strings */ |
266 | extern const char * | |
267 | rte_crypto_auth_algorithm_strings[]; | |
268 | ||
7c673cae FG |
269 | /** Symmetric Authentication / Hash Operations */ |
270 | enum rte_crypto_auth_operation { | |
271 | RTE_CRYPTO_AUTH_OP_VERIFY, /**< Verify authentication digest */ | |
272 | RTE_CRYPTO_AUTH_OP_GENERATE /**< Generate authentication digest */ | |
273 | }; | |
274 | ||
11fdf7f2 TL |
275 | /** Authentication operation name strings */ |
276 | extern const char * | |
277 | rte_crypto_auth_operation_strings[]; | |
278 | ||
7c673cae FG |
279 | /** |
280 | * Authentication / Hash transform data. | |
281 | * | |
282 | * This structure contains data relating to an authentication/hash crypto | |
283 | * transforms. The fields op, algo and digest_length are common to all | |
284 | * authentication transforms and MUST be set. | |
285 | */ | |
286 | struct rte_crypto_auth_xform { | |
287 | enum rte_crypto_auth_operation op; | |
288 | /**< Authentication operation type */ | |
289 | enum rte_crypto_auth_algorithm algo; | |
290 | /**< Authentication algorithm selection */ | |
291 | ||
292 | struct { | |
293 | uint8_t *data; /**< pointer to key data */ | |
9f95a23c | 294 | uint16_t length;/**< key length in bytes */ |
7c673cae FG |
295 | } key; |
296 | /**< Authentication key data. | |
297 | * The authentication key length MUST be less than or equal to the | |
298 | * block size of the algorithm. It is the callers responsibility to | |
299 | * ensure that the key length is compliant with the standard being used | |
300 | * (for example RFC 2104, FIPS 198a). | |
301 | */ | |
302 | ||
9f95a23c TL |
303 | struct { |
304 | uint16_t offset; | |
305 | /**< Starting point for Initialisation Vector or Counter, | |
306 | * specified as number of bytes from start of crypto | |
307 | * operation (rte_crypto_op). | |
308 | * | |
309 | * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and | |
310 | * for AES-GMAC, this is the authentication | |
311 | * Initialisation Vector (IV) value. | |
312 | * | |
313 | * - For KASUMI in F9 mode and other authentication | |
314 | * algorithms, this field is not used. | |
315 | * | |
316 | * For optimum performance, the data pointed to SHOULD | |
317 | * be 8-byte aligned. | |
318 | */ | |
319 | uint16_t length; | |
320 | /**< Length of valid IV data. | |
321 | * | |
322 | * - For SNOW3G in UIA2 mode, for ZUC in EIA3 mode and | |
323 | * for AES-GMAC, this is the length of the IV. | |
324 | * | |
325 | * - For KASUMI in F9 mode and other authentication | |
326 | * algorithms, this field is not used. | |
327 | * | |
328 | */ | |
329 | } iv; /**< Initialisation vector parameters */ | |
330 | ||
331 | uint16_t digest_length; | |
7c673cae FG |
332 | /**< Length of the digest to be returned. If the verify option is set, |
333 | * this specifies the length of the digest to be compared for the | |
334 | * session. | |
335 | * | |
11fdf7f2 TL |
336 | * It is the caller's responsibility to ensure that the |
337 | * digest length is compliant with the hash algorithm being used. | |
7c673cae | 338 | * If the value is less than the maximum length allowed by the hash, |
11fdf7f2 | 339 | * the result shall be truncated. |
7c673cae | 340 | */ |
9f95a23c TL |
341 | }; |
342 | ||
343 | ||
344 | /** Symmetric AEAD Algorithms */ | |
345 | enum rte_crypto_aead_algorithm { | |
346 | RTE_CRYPTO_AEAD_AES_CCM = 1, | |
347 | /**< AES algorithm in CCM mode. */ | |
348 | RTE_CRYPTO_AEAD_AES_GCM, | |
349 | /**< AES algorithm in GCM mode. */ | |
350 | RTE_CRYPTO_AEAD_LIST_END | |
351 | }; | |
352 | ||
353 | /** AEAD algorithm name strings */ | |
354 | extern const char * | |
355 | rte_crypto_aead_algorithm_strings[]; | |
356 | ||
357 | /** Symmetric AEAD Operations */ | |
358 | enum rte_crypto_aead_operation { | |
359 | RTE_CRYPTO_AEAD_OP_ENCRYPT, | |
360 | /**< Encrypt and generate digest */ | |
361 | RTE_CRYPTO_AEAD_OP_DECRYPT | |
362 | /**< Verify digest and decrypt */ | |
363 | }; | |
364 | ||
365 | /** Authentication operation name strings */ | |
366 | extern const char * | |
367 | rte_crypto_aead_operation_strings[]; | |
368 | ||
369 | struct rte_crypto_aead_xform { | |
370 | enum rte_crypto_aead_operation op; | |
371 | /**< AEAD operation type */ | |
372 | enum rte_crypto_aead_algorithm algo; | |
373 | /**< AEAD algorithm selection */ | |
374 | ||
375 | struct { | |
376 | uint8_t *data; /**< pointer to key data */ | |
377 | uint16_t length;/**< key length in bytes */ | |
378 | } key; | |
7c673cae | 379 | |
9f95a23c TL |
380 | struct { |
381 | uint16_t offset; | |
382 | /**< Starting point for Initialisation Vector or Counter, | |
383 | * specified as number of bytes from start of crypto | |
384 | * operation (rte_crypto_op). | |
385 | * | |
386 | * - For GCM mode, this is either the IV (if the length | |
387 | * is 96 bits) or J0 (for other sizes), where J0 is as | |
388 | * defined by NIST SP800-38D. Regardless of the IV | |
389 | * length, a full 16 bytes needs to be allocated. | |
390 | * | |
391 | * - For CCM mode, the first byte is reserved, and the | |
392 | * nonce should be written starting at &iv[1] (to allow | |
393 | * space for the implementation to write in the flags | |
394 | * in the first byte). Note that a full 16 bytes should | |
395 | * be allocated, even though the length field will | |
396 | * have a value less than this. | |
397 | * | |
398 | * For optimum performance, the data pointed to SHOULD | |
399 | * be 8-byte aligned. | |
400 | */ | |
401 | uint16_t length; | |
402 | /**< Length of valid IV data. | |
403 | * | |
404 | * - For GCM mode, this is either 12 (for 96-bit IVs) | |
405 | * or 16, in which case data points to J0. | |
406 | * | |
407 | * - For CCM mode, this is the length of the nonce, | |
408 | * which can be in the range 7 to 13 inclusive. | |
409 | */ | |
410 | } iv; /**< Initialisation vector parameters */ | |
411 | ||
412 | uint16_t digest_length; | |
413 | ||
414 | uint16_t aad_length; | |
7c673cae | 415 | /**< The length of the additional authenticated data (AAD) in bytes. |
9f95a23c TL |
416 | * For CCM mode, this is the length of the actual AAD, even though |
417 | * it is required to reserve 18 bytes before the AAD and padding | |
418 | * at the end of it, so a multiple of 16 bytes is allocated. | |
7c673cae FG |
419 | */ |
420 | }; | |
421 | ||
422 | /** Crypto transformation types */ | |
423 | enum rte_crypto_sym_xform_type { | |
424 | RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED = 0, /**< No xform specified */ | |
425 | RTE_CRYPTO_SYM_XFORM_AUTH, /**< Authentication xform */ | |
9f95a23c TL |
426 | RTE_CRYPTO_SYM_XFORM_CIPHER, /**< Cipher xform */ |
427 | RTE_CRYPTO_SYM_XFORM_AEAD /**< AEAD xform */ | |
7c673cae FG |
428 | }; |
429 | ||
430 | /** | |
431 | * Symmetric crypto transform structure. | |
432 | * | |
433 | * This is used to specify the crypto transforms required, multiple transforms | |
434 | * can be chained together to specify a chain transforms such as authentication | |
435 | * then cipher, or cipher then authentication. Each transform structure can | |
436 | * hold a single transform, the type field is used to specify which transform | |
437 | * is contained within the union | |
438 | */ | |
439 | struct rte_crypto_sym_xform { | |
440 | struct rte_crypto_sym_xform *next; | |
441 | /**< next xform in chain */ | |
442 | enum rte_crypto_sym_xform_type type | |
443 | ; /**< xform type */ | |
444 | RTE_STD_C11 | |
445 | union { | |
446 | struct rte_crypto_auth_xform auth; | |
447 | /**< Authentication / hash xform */ | |
448 | struct rte_crypto_cipher_xform cipher; | |
449 | /**< Cipher xform */ | |
9f95a23c TL |
450 | struct rte_crypto_aead_xform aead; |
451 | /**< AEAD xform */ | |
7c673cae FG |
452 | }; |
453 | }; | |
454 | ||
7c673cae FG |
455 | struct rte_cryptodev_sym_session; |
456 | ||
457 | /** | |
458 | * Symmetric Cryptographic Operation. | |
459 | * | |
460 | * This structure contains data relating to performing symmetric cryptographic | |
461 | * processing on a referenced mbuf data buffer. | |
462 | * | |
463 | * When a symmetric crypto operation is enqueued with the device for processing | |
464 | * it must have a valid *rte_mbuf* structure attached, via m_src parameter, | |
465 | * which contains the source data which the crypto operation is to be performed | |
466 | * on. | |
467 | * While the mbuf is in use by a crypto operation no part of the mbuf should be | |
468 | * changed by the application as the device may read or write to any part of the | |
469 | * mbuf. In the case of hardware crypto devices some or all of the mbuf | |
470 | * may be DMAed in and out of the device, so writing over the original data, | |
471 | * though only the part specified by the rte_crypto_sym_op for transformation | |
472 | * will be changed. | |
473 | * Out-of-place (OOP) operation, where the source mbuf is different to the | |
474 | * destination mbuf, is a special case. Data will be copied from m_src to m_dst. | |
475 | * The part copied includes all the parts of the source mbuf that will be | |
476 | * operated on, based on the cipher.data.offset+cipher.data.length and | |
477 | * auth.data.offset+auth.data.length values in the rte_crypto_sym_op. The part | |
478 | * indicated by the cipher parameters will be transformed, any extra data around | |
479 | * this indicated by the auth parameters will be copied unchanged from source to | |
480 | * destination mbuf. | |
481 | * Also in OOP operation the cipher.data.offset and auth.data.offset apply to | |
482 | * both source and destination mbufs. As these offsets are relative to the | |
483 | * data_off parameter in each mbuf this can result in the data written to the | |
484 | * destination buffer being at a different alignment, relative to buffer start, | |
485 | * to the data in the source buffer. | |
486 | */ | |
487 | struct rte_crypto_sym_op { | |
488 | struct rte_mbuf *m_src; /**< source mbuf */ | |
489 | struct rte_mbuf *m_dst; /**< destination mbuf */ | |
490 | ||
7c673cae FG |
491 | RTE_STD_C11 |
492 | union { | |
493 | struct rte_cryptodev_sym_session *session; | |
494 | /**< Handle for the initialised session context */ | |
495 | struct rte_crypto_sym_xform *xform; | |
496 | /**< Session-less API crypto operation parameters */ | |
9f95a23c TL |
497 | struct rte_security_session *sec_session; |
498 | /**< Handle for the initialised security session context */ | |
7c673cae FG |
499 | }; |
500 | ||
9f95a23c TL |
501 | RTE_STD_C11 |
502 | union { | |
7c673cae | 503 | struct { |
9f95a23c TL |
504 | struct { |
505 | uint32_t offset; | |
506 | /**< Starting point for AEAD processing, specified as | |
507 | * number of bytes from start of packet in source | |
508 | * buffer. | |
509 | */ | |
510 | uint32_t length; | |
511 | /**< The message length, in bytes, of the source buffer | |
512 | * on which the cryptographic operation will be | |
513 | * computed. This must be a multiple of the block size | |
514 | */ | |
515 | } data; /**< Data offsets and length for AEAD */ | |
516 | struct { | |
517 | uint8_t *data; | |
518 | /**< This points to the location where the digest result | |
519 | * should be inserted (in the case of digest generation) | |
520 | * or where the purported digest exists (in the case of | |
521 | * digest verification). | |
522 | * | |
523 | * At session creation time, the client specified the | |
524 | * digest result length with the digest_length member | |
525 | * of the @ref rte_crypto_auth_xform structure. For | |
526 | * physical crypto devices the caller must allocate at | |
527 | * least digest_length of physically contiguous memory | |
528 | * at this location. | |
529 | * | |
530 | * For digest generation, the digest result will | |
531 | * overwrite any data at this location. | |
532 | * | |
533 | * @note | |
534 | * For GCM (@ref RTE_CRYPTO_AEAD_AES_GCM), for | |
535 | * "digest result" read "authentication tag T". | |
536 | */ | |
537 | rte_iova_t phys_addr; | |
538 | /**< Physical address of digest */ | |
539 | } digest; /**< Digest parameters */ | |
540 | struct { | |
541 | uint8_t *data; | |
542 | /**< Pointer to Additional Authenticated Data (AAD) | |
543 | * needed for authenticated cipher mechanisms (CCM and | |
544 | * GCM) | |
545 | * | |
546 | * Specifically for CCM (@ref RTE_CRYPTO_AEAD_AES_CCM), | |
547 | * the caller should setup this field as follows: | |
548 | * | |
549 | * - the additional authentication data itself should | |
550 | * be written starting at an offset of 18 bytes into | |
551 | * the array, leaving room for the first block (16 bytes) | |
552 | * and the length encoding in the first two bytes of the | |
553 | * second block. | |
554 | * | |
555 | * - the array should be big enough to hold the above | |
556 | * fields, plus any padding to round this up to the | |
557 | * nearest multiple of the block size (16 bytes). | |
558 | * Padding will be added by the implementation. | |
559 | * | |
560 | * - Note that PMDs may modify the memory reserved | |
561 | * (first 18 bytes and the final padding). | |
562 | * | |
563 | * Finally, for GCM (@ref RTE_CRYPTO_AEAD_AES_GCM), the | |
564 | * caller should setup this field as follows: | |
565 | * | |
566 | * - the AAD is written in starting at byte 0 | |
567 | * - the array must be big enough to hold the AAD, plus | |
568 | * any space to round this up to the nearest multiple | |
569 | * of the block size (16 bytes). | |
570 | * | |
571 | */ | |
572 | rte_iova_t phys_addr; /**< physical address */ | |
573 | } aad; | |
574 | /**< Additional authentication parameters */ | |
575 | } aead; | |
7c673cae FG |
576 | |
577 | struct { | |
9f95a23c TL |
578 | struct { |
579 | struct { | |
580 | uint32_t offset; | |
581 | /**< Starting point for cipher processing, | |
582 | * specified as number of bytes from start | |
583 | * of data in the source buffer. | |
584 | * The result of the cipher operation will be | |
585 | * written back into the output buffer | |
586 | * starting at this location. | |
587 | * | |
588 | * @note | |
589 | * For SNOW 3G @ RTE_CRYPTO_CIPHER_SNOW3G_UEA2, | |
590 | * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8 | |
591 | * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3, | |
592 | * this field should be in bits. | |
593 | */ | |
594 | uint32_t length; | |
595 | /**< The message length, in bytes, of the | |
596 | * source buffer on which the cryptographic | |
597 | * operation will be computed. | |
598 | * This must be a multiple of the block size | |
599 | * if a block cipher is being used. This is | |
600 | * also the same as the result length. | |
601 | * | |
602 | * @note | |
603 | * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2, | |
604 | * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8 | |
605 | * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3, | |
606 | * this field should be in bits. | |
607 | */ | |
608 | } data; /**< Data offsets and length for ciphering */ | |
609 | } cipher; | |
610 | ||
611 | struct { | |
612 | struct { | |
613 | uint32_t offset; | |
614 | /**< Starting point for hash processing, | |
615 | * specified as number of bytes from start of | |
616 | * packet in source buffer. | |
617 | * | |
618 | * @note | |
619 | * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2, | |
620 | * KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9 | |
621 | * and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3, | |
622 | * this field should be in bits. | |
623 | * | |
624 | * @note | |
625 | * For KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9, | |
626 | * this offset should be such that | |
627 | * data to authenticate starts at COUNT. | |
628 | */ | |
629 | uint32_t length; | |
630 | /**< The message length, in bytes, of the source | |
631 | * buffer that the hash will be computed on. | |
632 | * | |
633 | * @note | |
634 | * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2, | |
635 | * KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9 | |
636 | * and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3, | |
637 | * this field should be in bits. | |
638 | * | |
639 | * @note | |
640 | * For KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9, | |
641 | * the length should include the COUNT, | |
642 | * FRESH, message, direction bit and padding | |
643 | * (to be multiple of 8 bits). | |
644 | */ | |
645 | } data; | |
646 | /**< Data offsets and length for authentication */ | |
647 | ||
648 | struct { | |
649 | uint8_t *data; | |
650 | /**< This points to the location where | |
651 | * the digest result should be inserted | |
652 | * (in the case of digest generation) | |
653 | * or where the purported digest exists | |
654 | * (in the case of digest verification). | |
655 | * | |
656 | * At session creation time, the client | |
657 | * specified the digest result length with | |
658 | * the digest_length member of the | |
659 | * @ref rte_crypto_auth_xform structure. | |
660 | * For physical crypto devices the caller | |
661 | * must allocate at least digest_length of | |
662 | * physically contiguous memory at this | |
663 | * location. | |
664 | * | |
665 | * For digest generation, the digest result | |
666 | * will overwrite any data at this location. | |
667 | * | |
668 | */ | |
669 | rte_iova_t phys_addr; | |
670 | /**< Physical address of digest */ | |
671 | } digest; /**< Digest parameters */ | |
672 | } auth; | |
673 | }; | |
674 | }; | |
675 | }; | |
7c673cae FG |
676 | |
677 | ||
678 | /** | |
679 | * Reset the fields of a symmetric operation to their default values. | |
680 | * | |
681 | * @param op The crypto operation to be reset. | |
682 | */ | |
683 | static inline void | |
684 | __rte_crypto_sym_op_reset(struct rte_crypto_sym_op *op) | |
685 | { | |
686 | memset(op, 0, sizeof(*op)); | |
7c673cae FG |
687 | } |
688 | ||
689 | ||
690 | /** | |
691 | * Allocate space for symmetric crypto xforms in the private data space of the | |
692 | * crypto operation. This also defaults the crypto xform type to | |
693 | * RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED and configures the chaining of the xforms | |
694 | * in the crypto operation | |
695 | * | |
696 | * @return | |
697 | * - On success returns pointer to first crypto xform in crypto operations chain | |
698 | * - On failure returns NULL | |
699 | */ | |
700 | static inline struct rte_crypto_sym_xform * | |
701 | __rte_crypto_sym_op_sym_xforms_alloc(struct rte_crypto_sym_op *sym_op, | |
702 | void *priv_data, uint8_t nb_xforms) | |
703 | { | |
704 | struct rte_crypto_sym_xform *xform; | |
705 | ||
706 | sym_op->xform = xform = (struct rte_crypto_sym_xform *)priv_data; | |
707 | ||
708 | do { | |
709 | xform->type = RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED; | |
710 | xform = xform->next = --nb_xforms > 0 ? xform + 1 : NULL; | |
711 | } while (xform); | |
712 | ||
713 | return sym_op->xform; | |
714 | } | |
715 | ||
716 | ||
717 | /** | |
718 | * Attach a session to a symmetric crypto operation | |
719 | * | |
720 | * @param sym_op crypto operation | |
721 | * @param sess cryptodev session | |
722 | */ | |
723 | static inline int | |
724 | __rte_crypto_sym_op_attach_sym_session(struct rte_crypto_sym_op *sym_op, | |
725 | struct rte_cryptodev_sym_session *sess) | |
726 | { | |
727 | sym_op->session = sess; | |
7c673cae FG |
728 | |
729 | return 0; | |
730 | } | |
731 | ||
732 | ||
733 | #ifdef __cplusplus | |
734 | } | |
735 | #endif | |
736 | ||
737 | #endif /* _RTE_CRYPTO_SYM_H_ */ |