From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 22E2129CB for ; Fri, 14 Jul 2017 11:31:29 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jul 2017 02:31:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,358,1496127600"; d="scan'208";a="126623572" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga005.fm.intel.com with ESMTP; 14 Jul 2017 02:31:26 -0700 Received: from irsmsx111.ger.corp.intel.com (10.108.20.4) by IRSMSX154.ger.corp.intel.com (163.33.192.96) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 14 Jul 2017 10:31:25 +0100 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.242]) by irsmsx111.ger.corp.intel.com ([169.254.2.25]) with mapi id 14.03.0319.002; Fri, 14 Jul 2017 10:31:25 +0100 From: "Trahe, Fiona" To: "De Lara Guarch, Pablo" , "Kusztal, ArkadiuszX" , "Griffin, John" , "Doherty, Declan" CC: "dev@dpdk.org" , "Trahe, Fiona" Thread-Topic: [PATCH] cryptodev: fix KASUMI F9 expected parameters Thread-Index: AQHS++7yPQ3G49ZMkUeUPapQguoHYqJTDPSw Date: Fri, 14 Jul 2017 09:31:24 +0000 Message-ID: <348A99DA5F5B7549AA880327E580B43589236266@IRSMSX101.ger.corp.intel.com> References: <20170713074450.63682-1-pablo.de.lara.guarch@intel.com> In-Reply-To: <20170713074450.63682-1-pablo.de.lara.guarch@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzc1NGRhZjEtYTg1ZC00MTNmLTgwZTAtMWZkMWU4NjczYWMzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ilwvbno5dWNZOGo2UndIc0dTK3c1REU2OUFMXC9vWGdJYTBqSUVFTk80S3VWTT0ifQ== x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] cryptodev: fix KASUMI F9 expected parameters X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 09:31:31 -0000 Hi Pablo, > -----Original Message----- > From: De Lara Guarch, Pablo > Sent: Thursday, July 13, 2017 8:45 AM > To: Trahe, Fiona ; Kusztal, ArkadiuszX ; Griffin, > John ; Doherty, Declan > Cc: dev@dpdk.org; De Lara Guarch, Pablo > Subject: [PATCH] cryptodev: fix KASUMI F9 expected parameters >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Fixes: 681f540da52b ("cryptodev: do not use AAD in wireless algorithms") >=20 > Signed-off-by: Pablo de Lara > --- > 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(-) >=20 > diff --git a/doc/guides/cryptodevs/kasumi.rst b/doc/guides/cryptodevs/kas= umi.rst > index bff9321..273ed18 100644 > --- a/doc/guides/cryptodevs/kasumi.rst > +++ b/doc/guides/cryptodevs/kasumi.rst > @@ -51,7 +51,7 @@ Limitations > ----------- >=20 > * 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-alig= ned. > * 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). >=20 > @@ -108,3 +108,20 @@ Example: > .. code-block:: console >=20 > ./l2fwd-crypto -l 6 -n 4 --vdev=3D"crypto_kasumi,socket_id=3D1,max_n= b_sessions=3D128" > + > +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, pa= ge 13): > +``_. > +Input buffer has to have COUNT (4 bytes), FRESH (4 bytes), MESSAGE and D= IRECTION (1 bit) > +concatenated. After the DIRECTION bit, a single '1' bit is appended, fol= lowed by > +between 0 and 7 '0' bits, so that the total length of the buffer is mult= iple 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 len= gth > +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.rs= t > 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 i= s by using the >=20 > 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, pa= ge 13): > +``_. > +Input buffer has to have COUNT (4 bytes), FRESH (4 bytes), MESSAGE and D= IRECTION (1 bit) > +concatenated. After the DIRECTION bit, a single '1' bit is appended, fol= lowed by > +between 0 and 7 '0' bits, so that the total length of the buffer is mult= iple 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 len= gth > +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/kasu= mi/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, >=20 > sess->auth_op =3D auth_xform->auth.op; >=20 > - sess->auth_iv_offset =3D auth_xform->auth.iv.offset; > - if (auth_xform->auth.iv.length !=3D 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 =3D 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; >=20 > for (i =3D 0; i < num_ops; i++) { > /* Data must be byte aligned */ > @@ -293,21 +283,15 @@ process_kasumi_hash_op(struct rte_crypto_op **ops, >=20 > src =3D rte_pktmbuf_mtod(ops[i]->sym->m_src, uint8_t *) + > (ops[i]->sym->auth.data.offset >> 3); > - iv_ptr =3D rte_crypto_op_ctod_offset(ops[i], uint8_t *, > - session->auth_iv_offset); > - iv =3D *((uint64_t *)(iv_ptr)); > /* Direction from next bit after end of message */ > - num_bytes =3D (length_in_bits >> 3) + 1; > - shift_bits =3D (BYTE_LEN - 1 - length_in_bits) % BYTE_LEN; > - direction =3D (src[num_bytes - 1] >> shift_bits) & 0x01; > + num_bytes =3D length_in_bits >> 3; >=20 > if (session->auth_op =3D=3D RTE_CRYPTO_AUTH_OP_VERIFY) { > dst =3D (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); >=20 > - 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) !=3D 0) > @@ -319,9 +303,8 @@ process_kasumi_hash_op(struct rte_crypto_op **ops, > } else { > dst =3D ops[i]->sym->auth.digest.data; >=20 > - 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[] =3D { > .max =3D 4, > .increment =3D 0 > }, > - .iv_size =3D { > - .min =3D 8, > - .max =3D 8, > - .increment =3D 0 > - }, > + .iv_size =3D { 0 }, > .aad_size =3D { 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; >=20 >=20 > diff --git a/drivers/crypto/qat/qat_crypto.c b/drivers/crypto/qat/qat_cry= pto.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 =3D op->sym->auth.data.offset >> 3; > auth_len =3D op->sym->auth.data.length >> 3; >=20 > - if (ctx->qat_hash_alg =3D=3D > - ICP_QAT_HW_AUTH_ALGO_KASUMI_F9) { > - if (do_cipher) { > - auth_len =3D auth_len + auth_ofs + 1 - > - ICP_QAT_HW_KASUMI_BLK_SZ; > - auth_ofs =3D ICP_QAT_HW_KASUMI_BLK_SZ; > - } else { > - auth_len =3D auth_len + auth_ofs + 1; > - auth_ofs =3D 0; > - } > - } else > - auth_param->u1.aad_adr =3D > + auth_param->u1.aad_adr =3D > rte_crypto_op_ctophys_offset(op, > ctx->auth_iv.offset); >=20 > diff --git a/drivers/crypto/qat/qat_crypto_capabilities.h b/drivers/crypt= o/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 =3D 4, \ > .increment =3D 0 \ > }, \ > - .iv_size =3D { \ > - .min =3D 8, \ > - .max =3D 8, \ > - .increment =3D 0 \ > - }, \ > + .iv_size =3D { 0 }, \ > .aad_size =3D { 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.