[dpdk-dev] [PATCH] cryptodev: fix KASUMI F9 expected parameters

[Trahe, Fiona]

Hi Pablo,

> -----Original Message-----
> From: De Lara Guarch, Pablo
> Sent: Thursday, July 13, 2017 8:45 AM
> To: Trahe, Fiona <fiona.trahe at intel.com>; Kusztal, ArkadiuszX <arkadiuszx.kusztal at intel.com>; Griffin,
> John <john.griffin at intel.com>; Doherty, Declan <declan.doherty at intel.com>
> Cc: dev at dpdk.org; De Lara Guarch, Pablo <pablo.de.lara.guarch at intel.com>
> Subject: [PATCH] cryptodev: fix KASUMI F9 expected parameters
> 
> For KASUMI F9 algorithm, COUNT, FRESH and DIRECTION
> input values need to be contiguous with
> the message, as described in the KASUMI and QAT PMD
> documentation.
> 
> Before, the COUNT and FRESH values were set
> as part of the AAD (now IV), but always set before
> the beginning of the message.
> Since now the IV is set after the crypto operation,
> it is not possible to have these values in the
> expected location.
> 
> Therefore, as these are required to be contiguous,
> cryptodev API will expect these them to be passed
> as a single buffer, already constructed, so
> authentication IV parameters not needed anymore.
> 
> Fixes: 681f540da52b ("cryptodev: do not use AAD in wireless algorithms")
> 
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch at intel.com>
> ---
>  doc/guides/cryptodevs/kasumi.rst                   |  19 ++-
>  doc/guides/cryptodevs/qat.rst                      |  18 +++
>  drivers/crypto/kasumi/rte_kasumi_pmd.c             |  27 +---
>  drivers/crypto/kasumi/rte_kasumi_pmd_ops.c         |   6 +-
>  drivers/crypto/kasumi/rte_kasumi_pmd_private.h     |   1 -
>  drivers/crypto/qat/qat_crypto.c                    |  13 +-
>  drivers/crypto/qat/qat_crypto_capabilities.h       |   6 +-
>  lib/librte_cryptodev/rte_crypto_sym.h              |  16 +-
>  test/test/test_cryptodev.c                         | 173 +++++++++++++--------
>  .../test/test_cryptodev_kasumi_hash_test_vectors.h | 102 +++---------
>  test/test/test_cryptodev_kasumi_test_vectors.h     |  72 +++++----
>  11 files changed, 226 insertions(+), 227 deletions(-)
> 
> diff --git a/doc/guides/cryptodevs/kasumi.rst b/doc/guides/cryptodevs/kasumi.rst
> index bff9321..273ed18 100644
> --- a/doc/guides/cryptodevs/kasumi.rst
> +++ b/doc/guides/cryptodevs/kasumi.rst
> @@ -51,7 +51,7 @@ Limitations
>  -----------
> 
>  * Chained mbufs are not supported.
> -* KASUMI(F9) supported only if hash offset field is byte-aligned.
> +* KASUMI(F9) supported only if hash offset and length field is byte-aligned.
>  * In-place bit-level operations for KASUMI(F8) are not supported
>    (if length and/or offset of data to be ciphered is not byte-aligned).
> 
> @@ -108,3 +108,20 @@ Example:
>  .. code-block:: console
> 
>      ./l2fwd-crypto -l 6 -n 4 --vdev="crypto_kasumi,socket_id=1,max_nb_sessions=128"
> +
> +Extra notes on KASUMI F9
> +------------------------
> +
> +When using KASUMI F9 authentication algorithm, the input buffer must be
> +constructed according to the 3GPP KASUMI specifications (section 4.4, page 13):
> +`<http://cryptome.org/3gpp/35201-900.pdf>`_.
> +Input buffer has to have COUNT (4 bytes), FRESH (4 bytes), MESSAGE and DIRECTION (1 bit)
> +concatenated. After the DIRECTION bit, a single '1' bit is appended, followed by
> +between 0 and 7 '0' bits, so that the total length of the buffer is multiple of 8 bits.
> +Note that the actual message can be any length, specified in bits.
> +
> +Once this buffer is passed this way, when creating the crypto operation,
> +length of data to authenticate (op.sym.auth.data.length) must be the length
> +of all the items described above, including the padding at the end.
> +Also, offset of data to authenticate (op.sym.auth.data.offset)
> +must be such that points at the start of the COUNT bytes.
> diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
> index b2d05e5..21c7f5d 100644
> --- a/doc/guides/cryptodevs/qat.rst
> +++ b/doc/guides/cryptodevs/qat.rst
> @@ -366,3 +366,21 @@ Another way to bind the VFs to the DPDK UIO driver is by using the
> 
>      cd to the top-level DPDK directory
>      ./usertools/dpdk-devbind.py -b igb_uio 0000:03:01.1
> +
> +
> +Extra notes on KASUMI F9
> +------------------------
> +
> +When using KASUMI F9 authentication algorithm, the input buffer must be
> +constructed according to the 3GPP KASUMI specifications (section 4.4, page 13):
> +`<http://cryptome.org/3gpp/35201-900.pdf>`_.
> +Input buffer has to have COUNT (4 bytes), FRESH (4 bytes), MESSAGE and DIRECTION (1 bit)
> +concatenated. After the DIRECTION bit, a single '1' bit is appended, followed by
> +between 0 and 7 '0' bits, so that the total length of the buffer is multiple of 8 bits.
> +Note that the actual message can be any length, specified in bits.
> +
> +Once this buffer is passed this way, when creating the crypto operation,
> +length of data to authenticate (op.sym.auth.data.length) must be the length
> +of all the items described above, including the padding at the end.
> +Also, offset of data to authenticate (op.sym.auth.data.offset)
> +must be such that points at the start of the COUNT bytes.
> diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd.c b/drivers/crypto/kasumi/rte_kasumi_pmd.c
> index cff40fb..0e12913 100644
> --- a/drivers/crypto/kasumi/rte_kasumi_pmd.c
> +++ b/drivers/crypto/kasumi/rte_kasumi_pmd.c
> @@ -142,12 +142,6 @@ kasumi_set_session_parameters(struct kasumi_session *sess,
> 
>  		sess->auth_op = auth_xform->auth.op;
> 
> -		sess->auth_iv_offset = auth_xform->auth.iv.offset;
> -		if (auth_xform->auth.iv.length != KASUMI_IV_LENGTH) {
> -			KASUMI_LOG_ERR("Wrong IV length");
> -			return -EINVAL;
> -		}
> -
>  		/* Initialize key */
>  		sso_kasumi_init_f9_key_sched(auth_xform->auth.key.data,
>  				&sess->pKeySched_hash);
> @@ -274,12 +268,8 @@ process_kasumi_hash_op(struct rte_crypto_op **ops,
>  	unsigned i;
>  	uint8_t processed_ops = 0;
>  	uint8_t *src, *dst;
> -	uint8_t *iv_ptr;
>  	uint32_t length_in_bits;
>  	uint32_t num_bytes;
> -	uint32_t shift_bits;
> -	uint64_t iv;
> -	uint8_t direction;
> 
>  	for (i = 0; i < num_ops; i++) {
>  		/* Data must be byte aligned */
> @@ -293,21 +283,15 @@ process_kasumi_hash_op(struct rte_crypto_op **ops,
> 
>  		src = rte_pktmbuf_mtod(ops[i]->sym->m_src, uint8_t *) +
>  				(ops[i]->sym->auth.data.offset >> 3);
> -		iv_ptr = rte_crypto_op_ctod_offset(ops[i], uint8_t *,
> -				session->auth_iv_offset);
> -		iv = *((uint64_t *)(iv_ptr));
>  		/* Direction from next bit after end of message */
> -		num_bytes = (length_in_bits >> 3) + 1;
> -		shift_bits = (BYTE_LEN - 1 - length_in_bits) % BYTE_LEN;
> -		direction = (src[num_bytes - 1] >> shift_bits) & 0x01;
> +		num_bytes = length_in_bits >> 3;
> 
>  		if (session->auth_op == RTE_CRYPTO_AUTH_OP_VERIFY) {
>  			dst = (uint8_t *)rte_pktmbuf_append(ops[i]->sym->m_src,
>  					KASUMI_DIGEST_LENGTH);
> +			sso_kasumi_f9_1_buffer(&session->pKeySched_hash, src,
> +					num_bytes, dst);
> 
> -			sso_kasumi_f9_1_buffer_user(&session->pKeySched_hash,
> -					iv, src,
> -					length_in_bits,	dst, direction);
>  			/* Verify digest. */
>  			if (memcmp(dst, ops[i]->sym->auth.digest.data,
>  					KASUMI_DIGEST_LENGTH) != 0)
> @@ -319,9 +303,8 @@ process_kasumi_hash_op(struct rte_crypto_op **ops,
>  		} else  {
>  			dst = ops[i]->sym->auth.digest.data;
> 
> -			sso_kasumi_f9_1_buffer_user(&session->pKeySched_hash,
> -					iv, src,
> -					length_in_bits, dst, direction);
> +			sso_kasumi_f9_1_buffer(&session->pKeySched_hash, src,
> +					num_bytes, dst);
>  		}
>  		processed_ops++;
>  	}
> diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
> b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
> index 1d9c0fc..569a8de 100644
> --- a/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
> +++ b/drivers/crypto/kasumi/rte_kasumi_pmd_ops.c
> @@ -56,11 +56,7 @@ static const struct rte_cryptodev_capabilities kasumi_pmd_capabilities[] = {
>  					.max = 4,
>  					.increment = 0
>  				},
> -				.iv_size = {
> -					.min = 8,
> -					.max = 8,
> -					.increment = 0
> -				},
> +				.iv_size = { 0 },
>  				.aad_size = { 0 }
>  			}, }
>  		}, }
> diff --git a/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
> b/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
> index 9315a79..0ce2a2e 100644
> --- a/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
> +++ b/drivers/crypto/kasumi/rte_kasumi_pmd_private.h
> @@ -96,7 +96,6 @@ struct kasumi_session {
>  	enum kasumi_operation op;
>  	enum rte_crypto_auth_operation auth_op;
>  	uint16_t cipher_iv_offset;
> -	uint16_t auth_iv_offset;
>  } __rte_cache_aligned;
> 
> 
> diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_crypto.c
> index 7e04f21..a5e16f4 100644
> --- a/drivers/crypto/qat/qat_crypto.c
> +++ b/drivers/crypto/qat/qat_crypto.c
> @@ -1195,18 +1195,7 @@ qat_write_hw_desc_entry(struct rte_crypto_op *op, uint8_t *out_msg,
>  			auth_ofs = op->sym->auth.data.offset >> 3;
>  			auth_len = op->sym->auth.data.length >> 3;
> 
> -			if (ctx->qat_hash_alg ==
> -					ICP_QAT_HW_AUTH_ALGO_KASUMI_F9) {
> -				if (do_cipher) {
> -					auth_len = auth_len + auth_ofs + 1 -
> -						ICP_QAT_HW_KASUMI_BLK_SZ;
> -					auth_ofs = ICP_QAT_HW_KASUMI_BLK_SZ;
> -				} else {
> -					auth_len = auth_len + auth_ofs + 1;
> -					auth_ofs = 0;
> -				}
> -			} else
> -				auth_param->u1.aad_adr =
> +			auth_param->u1.aad_adr =
>  					rte_crypto_op_ctophys_offset(op,
>  							ctx->auth_iv.offset);
> 
> diff --git a/drivers/crypto/qat/qat_crypto_capabilities.h b/drivers/crypto/qat/qat_crypto_capabilities.h
> index fee8ee1..7f9135d 100644
> --- a/drivers/crypto/qat/qat_crypto_capabilities.h
> +++ b/drivers/crypto/qat/qat_crypto_capabilities.h
> @@ -429,11 +429,7 @@
>  					.max = 4,			\
>  					.increment = 0			\
>  				},					\
> -				.iv_size = {				\
> -					.min = 8,			\
> -					.max = 8,			\
> -					.increment = 0			\
> -				},					\
> +				.iv_size = { 0 },			\
>  				.aad_size = { 0 }			\
>  			}, }						\
>  		}, }							\
> diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
> index f1b2f38..d4b403b 100644
> --- a/lib/librte_cryptodev/rte_crypto_sym.h
> +++ b/lib/librte_cryptodev/rte_crypto_sym.h
> @@ -343,9 +343,8 @@ struct rte_crypto_auth_xform {
>  		uint16_t length;
>  		/**< Length of valid IV data.
>  		 *
> -		 * - For KASUMI in F9 mode, SNOW3G in UIA2 mode, for
> -		 *   ZUC in EIA3 mode and for AES-GMAC, this is the length
> -		 *   of the IV.
> +		 * - For SNOW3G in UIA2 mode, for ZUC in EIA3 mode and
> +		 *   for AES-GMAC, this is the length of the IV.

[Fiona] I think it's worth adding here:
For Kasumi in F9 mode the IV field in not used and length should be set to 0.