From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id CC382A04F0 for ; Tue, 10 Dec 2019 16:01:56 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BECB41BF6E; Tue, 10 Dec 2019 16:01:56 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id D546C1BF74 for ; Tue, 10 Dec 2019 16:01:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575990115; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Pad+MTjP2sET2pSXo2LZd4aXzas6gQhj9p2bSNZSfQo=; b=E7wMoS7g6admZtJeRjgAMJicrT/11AH2hH6mEUBJGw+t2HnTLkAnC4WLM5Cwu2aj8kWrKN ee2QIPD7sS6sq/zMAhq45uV+qOFDzr8VkbIRXZWx0RIpeCJPexcR/z5OZsiMDUq+Mp9WQp qpA1sllBKCrlYuANe2++2HrSxBqomwc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-268-G4IXFjp_PO66lSz7ZMxA4Q-1; Tue, 10 Dec 2019 10:01:51 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 32EB91183E1C; Tue, 10 Dec 2019 15:01:50 +0000 (UTC) Received: from rh.redhat.com (ovpn-116-64.ams2.redhat.com [10.36.116.64]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2A1FE5DA7D; Tue, 10 Dec 2019 15:01:48 +0000 (UTC) From: Kevin Traynor To: Marcin Smoczynski Cc: Akhil Goyal , dpdk stable Date: Tue, 10 Dec 2019 14:59:31 +0000 Message-Id: <20191210145937.32755-57-ktraynor@redhat.com> In-Reply-To: <20191210145937.32755-1-ktraynor@redhat.com> References: <20191210145937.32755-1-ktraynor@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-MC-Unique: G4IXFjp_PO66lSz7ZMxA4Q-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: [dpdk-stable] patch 'examples/ipsec-secgw: fix GCM IV length' has been queued to LTS release 18.11.6 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi, FYI, your patch has been queued to LTS release 18.11.6 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 12/16/19. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasi= ng (ie: not only metadata diffs), please double check that the rebase was correctly done. Queued patches are on a temporary branch at: https://github.com/kevintraynor/dpdk-stable-queue This queued commit can be viewed at: https://github.com/kevintraynor/dpdk-stable-queue/commit/ad214b1dc868df1610= 1fc60a669eb1608ff2212a Thanks. Kevin. --- >From ad214b1dc868df16101fc60a669eb1608ff2212a Mon Sep 17 00:00:00 2001 From: Marcin Smoczynski Date: Thu, 31 Oct 2019 15:04:45 +0100 Subject: [PATCH] examples/ipsec-secgw: fix GCM IV length [ upstream commit ce00b504f19896604d60d121008b8a2df48ef114 ] The example IPsec application does not work properly when using AES-GCM with crypto_openssl. ESP with AES-GCM uses standard 96bit long algorithm IV ([1]) which later concatenated with be32(1) forms a J0 block. GCM specification ([2], chapter 7.1) states that when length of IV is different than 96b, in order to format a J0 block, GHASH function must be used. According to specification ([2], chapter 5.1.1) GCM implementations should support standard 96bit IVs, other lengths are optional. Every DPDK cryptodev supports 96bit IV and few of them supports 128bit IV as well (openssl, mrvl, ccp). When passing iv::length=3D16 to a cryptodev which does support standard IVs only (e.g. qat) it implicitly uses starting 96 bits. On the other hand, openssl follows specification and uses GHASH to compute J0 for that case which results in different than expected J0 values used for encryption/decryption. Fix an inability to use AES-GCM with crypto_openssl by changing IV length to the standard value of 12. [1] RFC4106, section "4. Nonce format" and "3.1. Initialization Vector" https://tools.ietf.org/html/rfc4106 [2] NIST SP800-38D https://csrc.nist.gov/publications/detail/sp/800-38d/final Fixes: 0fbd75a99f ("cryptodev: move IV parameters to session") Signed-off-by: Marcin Smoczynski Acked-by: Akhil Goyal --- examples/ipsec-secgw/sa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c index 45b810366..dd01f1fbc 100644 --- a/examples/ipsec-secgw/sa.c +++ b/examples/ipsec-secgw/sa.c @@ -912,5 +912,5 @@ sa_add_rules(struct sa_ctx *sa_ctx, const struct ipsec_= sa entries[], =20 =09=09if (sa->aead_algo =3D=3D RTE_CRYPTO_AEAD_AES_GCM) { -=09=09=09iv_length =3D 16; +=09=09=09iv_length =3D 12; =20 =09=09=09sa_ctx->xf[idx].a.type =3D RTE_CRYPTO_SYM_XFORM_AEAD; --=20 2.21.0 --- Diff of the applied patch vs upstream commit (please double-check if non-= empty: --- --- -=092019-12-10 14:49:42.835102506 +0000 +++ 0057-examples-ipsec-secgw-fix-GCM-IV-length.patch=092019-12-10 14:49:39= .098456910 +0000 @@ -1 +1 @@ -From ce00b504f19896604d60d121008b8a2df48ef114 Mon Sep 17 00:00:00 2001 +From ad214b1dc868df16101fc60a669eb1608ff2212a Mon Sep 17 00:00:00 2001 @@ -5,0 +6,2 @@ +[ upstream commit ce00b504f19896604d60d121008b8a2df48ef114 ] + @@ -32 +33,0 @@ -Cc: stable@dpdk.org @@ -41 +42 @@ -index 4cb90857c..a8dee342e 100644 +index 45b810366..dd01f1fbc 100644 @@ -44 +45,2 @@ -@@ -986,5 +986,5 @@ sa_add_rules(struct sa_ctx *sa_ctx, const struct ipsec= _sa entries[], +@@ -912,5 +912,5 @@ sa_add_rules(struct sa_ctx *sa_ctx, const struct ipsec= _sa entries[], +=20 @@ -46 +47,0 @@ - =09=09=09struct rte_ipsec_session *ips;