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