From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Azarewicz, PiotrX T" <piotrx.t.azarewicz@intel.com>
Subject: Re: [PATCH v2 1/3] crypto/aesni_gcm: fix J0 padding
 bytes	for GCM
Date: Mon, 2 Jan 2017 08:50:37 +0000
Message-ID: <4837007523CC9A4B9414D20C13DE6E6413758F5E@IRSMSX102.ger.corp.intel.com>
References: <1482481493-4369-1-git-send-email-arkadiuszx.kusztal@intel.com>
 <1482481493-4369-2-git-send-email-arkadiuszx.kusztal@intel.com>
 <4837007523CC9A4B9414D20C13DE6E6413756B1A@IRSMSX102.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "Trahe, Fiona" <fiona.trahe@intel.com>, "De Lara Guarch, Pablo"
 <pablo.de.lara.guarch@intel.com>, "Griffin, John" <john.griffin@intel.com>,
 "Jain, Deepak K" <deepak.k.jain@intel.com>, "Doherty, Declan"
 <declan.doherty@intel.com>, "Kusztal, ArkadiuszX"
 <arkadiuszx.kusztal@intel.com>
To: "Azarewicz, PiotrX T" <piotrx.t.azarewicz@intel.com>, "Kusztal,
 ArkadiuszX" <arkadiuszx.kusztal@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mga07.intel.com (mga07.intel.com [134.134.136.100])
 by dpdk.org (Postfix) with ESMTP id 3AE265592
 for <dev@dpdk.org>; Mon,  2 Jan 2017 09:50:41 +0100 (CET)
In-Reply-To: <4837007523CC9A4B9414D20C13DE6E6413756B1A@IRSMSX102.ger.corp.intel.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Arek,

> > Subject: [dpdk-dev] [PATCH v2 1/3] crypto/aesni_gcm: fix J0 padding
> > bytes for GCM
> >
> > This commit fixes pre-counter block (J0) padding by clearing four most
> > significant bytes before setting initial counter value.
> >
> > Fixes: b2bb3597470c ("crypto/aesni_gcm: move pre-counter block to
> > driver")
> >
> > Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
> > ---
> >  drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> > b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> > index dba5e15..af3d60f 100644
> > --- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> > +++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
> > @@ -40,6 +40,7 @@
> >  #include <rte_vdev.h>
> >  #include <rte_malloc.h>
> >  #include <rte_cpuflags.h>
> > +#include <rte_byteorder.h>
> >
> >  #include "aesni_gcm_pmd_private.h"
> >
> > @@ -241,7 +242,8 @@ process_gcm_crypto_op(struct aesni_gcm_qp *qp,
> > struct rte_crypto_sym_op *op,
> >  	 * to set BE LSB to 1, driver expects that 16B is allocated
>=20
> I think that 16B expected by driver while only 12B IV is supported is not=
 clear
> from user perspective.
> I think that we should expect 12B only and allocate 16B locally.

I didn't notice that this exception is also described in rte_crypto_sym.h, =
so this is fine.

>=20
> >  	 */
> >  	if (op->cipher.iv.length =3D=3D 12) {
> > -		op->cipher.iv.data[15] =3D 1;
> > +		uint32_t *iv_padd =3D (uint32_t *)&op->cipher.iv.data[12];
> > +		*iv_padd =3D rte_bswap32(1);
>=20
> Should not be that the last byte (number 15) always be set to 1?

I didn't notice that this code will always run in little-endian machine, so=
 this is fine too.

>=20
> >  	}
> >
> >  	if (op->auth.aad.length !=3D 12 && op->auth.aad.length !=3D 8 &&
> > --
> > 2.1.0

Acked-by: Piotr Azarewicz <piotrx.t.azarewicz@intel.com>