[dpdk-stable] patch 'examples/ipsec-secgw: fix GCM IV length' has been queued to LTS release 17.11.10

luca.boccassi at gmail.com luca.boccassi at gmail.com
Thu Dec 19 15:34:11 CET 2019


Hi,

FYI, your patch has been queued to LTS release 17.11.10

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/21/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 rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Thanks.

Luca Boccassi

---
>From 0a742f17f247694e9710d4574e52d131216086ad Mon Sep 17 00:00:00 2001
From: Marcin Smoczynski <marcinx.smoczynski at intel.com>
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=16 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 <marcinx.smoczynski at intel.com>
Acked-by: Akhil Goyal <akhil.goyal at nxp.com>
---
 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 eb83d94cdc..67127d0401 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -822,7 +822,7 @@ sa_add_rules(struct sa_ctx *sa_ctx, const struct ipsec_sa entries[],
 		}
 
 		if (sa->aead_algo == RTE_CRYPTO_AEAD_AES_GCM) {
-			iv_length = 16;
+			iv_length = 12;
 
 			sa_ctx->xf[idx].a.type = RTE_CRYPTO_SYM_XFORM_AEAD;
 			sa_ctx->xf[idx].a.aead.algo = sa->aead_algo;
-- 
2.20.1

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2019-12-19 14:32:30.462404069 +0000
+++ 0104-examples-ipsec-secgw-fix-GCM-IV-length.patch	2019-12-19 14:32:26.241300522 +0000
@@ -1,8 +1,10 @@
-From ce00b504f19896604d60d121008b8a2df48ef114 Mon Sep 17 00:00:00 2001
+From 0a742f17f247694e9710d4574e52d131216086ad Mon Sep 17 00:00:00 2001
 From: Marcin Smoczynski <marcinx.smoczynski at intel.com>
 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.
 
@@ -29,7 +31,6 @@
     https://csrc.nist.gov/publications/detail/sp/800-38d/final
 
 Fixes: 0fbd75a99f ("cryptodev: move IV parameters to session")
-Cc: stable at dpdk.org
 
 Signed-off-by: Marcin Smoczynski <marcinx.smoczynski at intel.com>
 Acked-by: Akhil Goyal <akhil.goyal at nxp.com>
@@ -38,13 +39,13 @@
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
-index 4cb90857c7..a8dee342eb 100644
+index eb83d94cdc..67127d0401 100644
 --- a/examples/ipsec-secgw/sa.c
 +++ b/examples/ipsec-secgw/sa.c
-@@ -985,7 +985,7 @@ sa_add_rules(struct sa_ctx *sa_ctx, const struct ipsec_sa entries[],
+@@ -822,7 +822,7 @@ sa_add_rules(struct sa_ctx *sa_ctx, const struct ipsec_sa entries[],
+ 		}
  
  		if (sa->aead_algo == RTE_CRYPTO_AEAD_AES_GCM) {
- 			struct rte_ipsec_session *ips;
 -			iv_length = 16;
 +			iv_length = 12;
  


More information about the stable mailing list