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 48F09A04F0 for ; Thu, 19 Dec 2019 15:40:36 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3C3F81BFE9; Thu, 19 Dec 2019 15:40:36 +0100 (CET) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by dpdk.org (Postfix) with ESMTP id 73F731BFED for ; Thu, 19 Dec 2019 15:40:34 +0100 (CET) Received: by mail-wm1-f54.google.com with SMTP id p17so5887873wmb.0 for ; Thu, 19 Dec 2019 06:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=GpkKEZd5nZnRq+unudxXnc2Cx8mYEMbOcNf9r0ZJ9Mw=; b=MerssjRl7emVB8w28h7u7HuSQa11QFJV+ZauKlf0wqclaJRiEVX8UomFDjkd/jOFTy l5/03LuYsCtwTW0yRRwtDpYHZfW1mI0wehbEhYnydbsMj4cjepeOdyaGlaOa89Fu+coi Snge1bK5O7B3L7iDRjw3sHgS88dx3JiaMVEVKGTM5YikCMSEYYtyTSRKTUXEmd0Uqe0H p+M7QkJ45Wd+XVnddOXIRrJiUeNuM7ZReIN6coQQj36jqrlctf9Nie9N+QBIc+gxzc+P abVpkFsJnkCmrEzdUa20FtoWOQeybJXQLcuN1FaLli3dWyk38/xen5XA5xYbrOKyCmq5 nKLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=GpkKEZd5nZnRq+unudxXnc2Cx8mYEMbOcNf9r0ZJ9Mw=; b=bO9xCI/K3+FM6ljy80O5xHOyq9RE3mll+Es+zo/Cfd6+8knvXcDDhOuMfjKcxJeaK7 CvSh5pPdAlvibx1iUvLvRAYypHIYn94shduSIV75Rk68qeuLluF8LxxNwJkBc8ZfUbA+ 1UdAq7lkA4KyCf/d0PUPRY7Yf5paVvWwKrrWR3PtL1CYs1G13X96j8zmjXZgbR8oq9L0 6nD3vuDIqjQ0Wm0qAcWNzKVlRmW90aUxPlNl2aM+j2dpzeyAaQNmSb/C6+1fgy5KPhqi Wux4Cz5zCNDvyWrjG6nZ3GW3iNPKvkHoaPZ2n4cACU5VfjfCAud1TBEi2JtiqKL6aMCa yEhw== X-Gm-Message-State: APjAAAUh5xojwihg9CNCFH6rb6s9INQQ3iL35uI41Abv3kJzT387En/b PHUkWVzF9cxaB+2lysqaBdYkysHkOyE= X-Google-Smtp-Source: APXvYqzQ4owfVg8F7/nM+2TJYAphQNbiU6BRnx+SIfKv1BvNPNTrmAdto/8D2/LKO26TBGwveR7qDA== X-Received: by 2002:a7b:c38c:: with SMTP id s12mr10403710wmj.96.1576766434201; Thu, 19 Dec 2019 06:40:34 -0800 (PST) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id 188sm6710892wmd.1.2019.12.19.06.40.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Dec 2019 06:40:33 -0800 (PST) From: luca.boccassi@gmail.com To: Marcin Smoczynski Cc: Akhil Goyal , dpdk stable Date: Thu, 19 Dec 2019 14:34:11 +0000 Message-Id: <20191219143447.21506-104-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20191219143447.21506-1-luca.boccassi@gmail.com> References: <20191219143447.21506-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'examples/ipsec-secgw: fix GCM IV length' has been queued to LTS release 17.11.10 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 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 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 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 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 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@dpdk.org Signed-off-by: Marcin Smoczynski Acked-by: Akhil Goyal @@ -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;