From patchwork Fri Feb 18 16:34:40 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "De Lara Guarch, Pablo" X-Patchwork-Id: 107812 X-Patchwork-Delegate: gakhil@marvell.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F399FA0032; Fri, 18 Feb 2022 17:34:57 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E21BE40E2D; Fri, 18 Feb 2022 17:34:57 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 5DB3940E28; Fri, 18 Feb 2022 17:34:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645202096; x=1676738096; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/j17sG4D23+B4zPQiDj1DUH8r0DJGveA/cIAqkkmaTk=; b=liBS6s+IUNaGQhrA82JwNMOoMx2ZrY27FSc47C+k2duiAm+V0KJTMOId HY8EA0rqluPn0f63N6E/73NCrKEZetiXAaAfUyXFCbelEnjOBiLuM4Feg nx82uwl7PJEWDNvNCOKA0y6NdX5nvcM3X8n/FinTosSWrMGUZDXvnV35Q j8ijahQiT15huo39f6OIGDdGEMl/jqAnjJt/8JXsRJQS/rl9/ucDzJ4P8 dYR0sk4kQmz56vofBF9/cCVZ8bVXpTLxCcve8B6xPSec4DiExInQlNRmq 9IZVeeBaly85FdymGOmzzVr2y23EWo3P5y1eK3vsowbsUU1zKYlBwCFws Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10261"; a="275757267" X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="275757267" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 08:34:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="546343807" Received: from silpixa00400493.ir.intel.com ([10.237.213.136]) by orsmga008.jf.intel.com with ESMTP; 18 Feb 2022 08:34:53 -0800 From: Pablo de Lara To: roy.fan.zhang@intel.com Cc: dev@dpdk.org, Pablo de Lara , piotrx.bronowski@intel.com, stable@dpdk.org Subject: [PATCH 1/4] crypto/ipsec_mb: check for missing operation types Date: Fri, 18 Feb 2022 16:34:40 +0000 Message-Id: <20220218163443.3520756-2-pablo.de.lara.guarch@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220218163443.3520756-1-pablo.de.lara.guarch@intel.com> References: <20220218163443.3520756-1-pablo.de.lara.guarch@intel.com> MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org When processing crypto operations in ZUC PMD, there were two operation types that were set at session level, but not checked when the operations are enqueued and processed, leaving the buffers untouched silently. Fixes: cde8df1bda9d ("crypto/ipsec_mb: move zuc PMD") Cc: piotrx.bronowski@intel.com Cc: stable@dpdk.org Signed-off-by: Pablo de Lara --- drivers/crypto/ipsec_mb/pmd_zuc.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/ipsec_mb/pmd_zuc.c b/drivers/crypto/ipsec_mb/pmd_zuc.c index 2eae1d1ec7..ec83d96dfc 100644 --- a/drivers/crypto/ipsec_mb/pmd_zuc.c +++ b/drivers/crypto/ipsec_mb/pmd_zuc.c @@ -198,7 +198,7 @@ process_ops(struct rte_crypto_op **ops, enum ipsec_mb_operation op_type, struct ipsec_mb_qp *qp, uint8_t num_ops) { unsigned int i; - unsigned int processed_ops; + unsigned int processed_ops = 0; switch (op_type) { case IPSEC_MB_OP_ENCRYPT_ONLY: @@ -212,18 +212,21 @@ process_ops(struct rte_crypto_op **ops, enum ipsec_mb_operation op_type, num_ops); break; case IPSEC_MB_OP_ENCRYPT_THEN_HASH_GEN: + case IPSEC_MB_OP_DECRYPT_THEN_HASH_VERIFY: processed_ops = process_zuc_cipher_op(qp, ops, sessions, num_ops); process_zuc_hash_op(qp, ops, sessions, processed_ops); break; case IPSEC_MB_OP_HASH_VERIFY_THEN_DECRYPT: + case IPSEC_MB_OP_HASH_GEN_THEN_ENCRYPT: processed_ops = process_zuc_hash_op(qp, ops, sessions, num_ops); process_zuc_cipher_op(qp, ops, sessions, processed_ops); break; default: /* Operation not supported. */ - processed_ops = 0; + for (i = 0; i < num_ops; i++) + ops[i]->status = RTE_CRYPTO_OP_STATUS_INVALID_SESSION; } for (i = 0; i < num_ops; i++) { From patchwork Fri Feb 18 16:34:41 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "De Lara Guarch, Pablo" X-Patchwork-Id: 107813 X-Patchwork-Delegate: gakhil@marvell.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1620EA0032; Fri, 18 Feb 2022 17:35:10 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 09E6941143; Fri, 18 Feb 2022 17:35:10 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 1ED4F4068B; Fri, 18 Feb 2022 17:35:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645202108; x=1676738108; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=f2Qbj+GMcphl3pqIJVjVfUafV+l63hD/Uik1RYxAb+o=; b=KJLsUUMo0k4fSjczBiANTBdh6cHuE9kTy/uJJ2Jq9w7Wjj/i4aHoqAEF ADMRpUR5giOEtbjpfhIxEjdF4EkAzd9F30qp8IVT41nQMzXmFHr/sqkqL x7gefrhIpwtFR+FdJdEw8MiEY90lxX77FQwfwTBmGgoQqj1Dhyc++QEoZ YZHB9qJuLlrpnWVCM667Ou+yE8uhdabLi15I09VTknNIacdTOh+6GTRAb ZWU7JPRThfPIuMtanNCTsnrXtw9WT/g4+xsD0nkcO9oCceNuxkB4sn1BQ bo5CU941H9FYnLK7C/fRQ1Co8lXko9wWyFMOwd/QXbgdyKnhkvgKeAyRB w==; X-IronPort-AV: E=McAfee;i="6200,9189,10261"; a="251101731" X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="251101731" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 08:35:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="546344016" Received: from silpixa00400493.ir.intel.com ([10.237.213.136]) by orsmga008.jf.intel.com with ESMTP; 18 Feb 2022 08:35:06 -0800 From: Pablo de Lara To: roy.fan.zhang@intel.com Cc: dev@dpdk.org, Pablo de Lara , stable@dpdk.org Subject: [PATCH 2/4] crypto/ipsec_mb: fix ZUC authentication verify Date: Fri, 18 Feb 2022 16:34:41 +0000 Message-Id: <20220218163443.3520756-3-pablo.de.lara.guarch@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220218163443.3520756-1-pablo.de.lara.guarch@intel.com> References: <20220218163443.3520756-1-pablo.de.lara.guarch@intel.com> MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org ZUC authentication is done over multiple buffers at a time. When authentication verification is done, multiple scratch buffers are using to generate the tags that will be compared afterwards. However, the same scratch buffer was used always, instead of having different ones for each crypto operation. Fixes: 0b133c36ad7d ("crypto/zuc: support IPsec Multi-buffer lib v0.54") Cc: pablo.de.lara.guarch@intel.com Cc: stable@dpdk.org Signed-off-by: Pablo de Lara --- drivers/crypto/ipsec_mb/pmd_zuc.c | 2 +- drivers/crypto/ipsec_mb/pmd_zuc_priv.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/ipsec_mb/pmd_zuc.c b/drivers/crypto/ipsec_mb/pmd_zuc.c index ec83d96dfc..07cf1462d2 100644 --- a/drivers/crypto/ipsec_mb/pmd_zuc.c +++ b/drivers/crypto/ipsec_mb/pmd_zuc.c @@ -166,7 +166,7 @@ process_zuc_hash_op(struct ipsec_mb_qp *qp, struct rte_crypto_op **ops, hash_keys[i] = sess->pKey_hash; if (sess->auth_op == RTE_CRYPTO_AUTH_OP_VERIFY) - dst[i] = (uint32_t *)qp_data->temp_digest; + dst[i] = (uint32_t *)qp_data->temp_digest[i]; else dst[i] = (uint32_t *)ops[i]->sym->auth.digest.data; diff --git a/drivers/crypto/ipsec_mb/pmd_zuc_priv.h b/drivers/crypto/ipsec_mb/pmd_zuc_priv.h index 46d5bfae37..76fd6758c2 100644 --- a/drivers/crypto/ipsec_mb/pmd_zuc_priv.h +++ b/drivers/crypto/ipsec_mb/pmd_zuc_priv.h @@ -75,7 +75,7 @@ struct zuc_session { struct zuc_qp_data { - uint8_t temp_digest[ZUC_DIGEST_LENGTH]; + uint8_t temp_digest[ZUC_MAX_BURST][ZUC_DIGEST_LENGTH]; /* *< Buffers used to store the digest generated * by the driver when verifying a digest provided * by the user (using authentication verify operation) From patchwork Fri Feb 18 16:34:42 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "De Lara Guarch, Pablo" X-Patchwork-Id: 107814 X-Patchwork-Delegate: gakhil@marvell.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0F808A0032; Fri, 18 Feb 2022 17:35:17 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 00A8441152; Fri, 18 Feb 2022 17:35:17 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 9D4F440141; Fri, 18 Feb 2022 17:35:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645202114; x=1676738114; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=EvJ41HASOG00fe/pQeYPIrYSbihg9Bx0GmmbmHUgIuo=; b=cUpU75yn6cTZybqSSRYNJ9NyLlWUoNT/yjV+dHpHadWZIb2zYNSDatBc Xmio07XJUTUxHM+/RQUj55f4Eqc/Y1H52nBDwAFMVL3OH6gZ3OqxXCsk3 mPTF6EWElWtLRp+At8rEzOdqlufjFQtnrqhJYkZaTDGYXW3R2TREDHotk hT829gHS1O56GrEpHIy3D6FpVzElrGxshr0MJOaOWrOI1JrybICaCT6gB uU9BT6S/tR+IQw7djb5oXxLVTCK2XFWUV6jFA4H3OgaIUXZbvMBTTRk39 v30A4/V6/QvcPVDniUK3fSEAI4FuV1coNpn8ff7ZLx/3snVTazgR+fPVI g==; X-IronPort-AV: E=McAfee;i="6200,9189,10261"; a="314423629" X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="314423629" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 08:35:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="546344117" Received: from silpixa00400493.ir.intel.com ([10.237.213.136]) by orsmga008.jf.intel.com with ESMTP; 18 Feb 2022 08:35:10 -0800 From: Pablo de Lara To: roy.fan.zhang@intel.com Cc: dev@dpdk.org, Pablo de Lara , stable@dpdk.org Subject: [PATCH 3/4] crypto/ipsec_mb: fix crypto operation overwrite Date: Fri, 18 Feb 2022 16:34:42 +0000 Message-Id: <20220218163443.3520756-4-pablo.de.lara.guarch@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220218163443.3520756-1-pablo.de.lara.guarch@intel.com> References: <20220218163443.3520756-1-pablo.de.lara.guarch@intel.com> MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org ZUC PMD batches crypto operations depending on their type (encryption + tag generation, tag verification + decryption, etc), to allow parallelization. The array used to store the pointers to these operations was always the same array provided by dequeue_burst() function, and it was looping around the same positions (from 0 to ZUC_MAX_BURST - 1). A new internal array is used to avoid overwriting the pointers of the array provided by dequeue_burst() function. Fixes: cf7685d68f00 ("crypto/zuc: add driver for ZUC library") Cc: pablo.de.lara.guarch@intel.com Cc: stable@dpdk.org Signed-off-by: Pablo de Lara --- drivers/crypto/ipsec_mb/pmd_zuc.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/crypto/ipsec_mb/pmd_zuc.c b/drivers/crypto/ipsec_mb/pmd_zuc.c index 07cf1462d2..e36c7092d6 100644 --- a/drivers/crypto/ipsec_mb/pmd_zuc.c +++ b/drivers/crypto/ipsec_mb/pmd_zuc.c @@ -259,6 +259,7 @@ zuc_pmd_dequeue_burst(void *queue_pair, struct zuc_session *curr_sess; struct zuc_session *sessions[ZUC_MAX_BURST]; + struct rte_crypto_op *int_c_ops[ZUC_MAX_BURST]; enum ipsec_mb_operation prev_zuc_op = IPSEC_MB_OP_NOT_SUPPORTED; enum ipsec_mb_operation curr_zuc_op; struct ipsec_mb_qp *qp = queue_pair; @@ -290,11 +291,11 @@ zuc_pmd_dequeue_burst(void *queue_pair, */ if (burst_size == 0) { prev_zuc_op = curr_zuc_op; - c_ops[0] = curr_c_op; + int_c_ops[0] = curr_c_op; sessions[0] = curr_sess; burst_size++; } else if (curr_zuc_op == prev_zuc_op) { - c_ops[burst_size] = curr_c_op; + int_c_ops[burst_size] = curr_c_op; sessions[burst_size] = curr_sess; burst_size++; /* @@ -302,7 +303,7 @@ zuc_pmd_dequeue_burst(void *queue_pair, * process them, and start a new batch. */ if (burst_size == ZUC_MAX_BURST) { - processed_ops = process_ops(c_ops, curr_zuc_op, + processed_ops = process_ops(int_c_ops, curr_zuc_op, sessions, qp, burst_size); if (processed_ops < burst_size) { burst_size = 0; @@ -316,7 +317,7 @@ zuc_pmd_dequeue_burst(void *queue_pair, * Different operation type, process the ops * of the previous type. */ - processed_ops = process_ops(c_ops, prev_zuc_op, + processed_ops = process_ops(int_c_ops, prev_zuc_op, sessions, qp, burst_size); if (processed_ops < burst_size) { burst_size = 0; @@ -326,7 +327,7 @@ zuc_pmd_dequeue_burst(void *queue_pair, burst_size = 0; prev_zuc_op = curr_zuc_op; - c_ops[0] = curr_c_op; + int_c_ops[0] = curr_c_op; sessions[0] = curr_sess; burst_size++; } @@ -334,7 +335,7 @@ zuc_pmd_dequeue_burst(void *queue_pair, if (burst_size != 0) { /* Process the crypto ops of the last operation type. */ - processed_ops = process_ops(c_ops, prev_zuc_op, + processed_ops = process_ops(int_c_ops, prev_zuc_op, sessions, qp, burst_size); } From patchwork Fri Feb 18 16:34:43 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "De Lara Guarch, Pablo" X-Patchwork-Id: 107815 X-Patchwork-Delegate: gakhil@marvell.com Return-Path: X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C1C62A0032; Fri, 18 Feb 2022 17:35:22 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 057CF41156; Fri, 18 Feb 2022 17:35:21 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 76C8941150; Fri, 18 Feb 2022 17:35:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645202118; x=1676738118; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=pbKi4CFCfWocbEVt+clOsKpywCbHE20qP8XC+DLh+4U=; b=OvaySl3qycZh7Xwqe4HXG0Jb3CX7PG4wTlb/KkzRmHqGMGEhUY5LMb06 ciwpKH5/wOsKmfSXSs7aORXcDhQEuBfcP5oobOe+JCpypJ+pbAVZbXMz9 dGRUtGxwTDV7unPiwQ/6xxxoU9flAfRzJb4QM3MXhIjl5tM0WxgvjJwuc vEjZ5rGyMrUV35kfiICv59YW8lqZed63fwHhhpzNBQ6wbfdwkHFnuzRnb QhlaLBonGJX+etO3UxUJYrYnm2UOxvnL7r168wZpbxjc+Ed3SRzuNT0+i dGJGvS5Uhu603QF1AJR1FHXVZg5q8TKBT3pDMe3COqOUXrkcgXFrpwxay Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10261"; a="314423643" X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="314423643" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 08:35:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,379,1635231600"; d="scan'208";a="546344200" Received: from silpixa00400493.ir.intel.com ([10.237.213.136]) by orsmga008.jf.intel.com with ESMTP; 18 Feb 2022 08:35:16 -0800 From: Pablo de Lara To: roy.fan.zhang@intel.com Cc: dev@dpdk.org, Pablo de Lara , stable@dpdk.org Subject: [PATCH 4/4] crypto/ipsec_mb: fix length and offset settings Date: Fri, 18 Feb 2022 16:34:43 +0000 Message-Id: <20220218163443.3520756-5-pablo.de.lara.guarch@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220218163443.3520756-1-pablo.de.lara.guarch@intel.com> References: <20220218163443.3520756-1-pablo.de.lara.guarch@intel.com> MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org KASUMI, SNOW3G and ZUC require lengths and offsets to be set in bits or bytes depending on the algorithm. There were some algorithms that were mixing these two, so this commit is fixing this issue. Fixes: ae8e085c608d ("crypto/aesni_mb: support KASUMI F8/F9") Fixes: 6c42e0cf4d12 ("crypto/aesni_mb: support SNOW3G-UEA2/UIA2") Fixes: fd8df85487c4 ("crypto/aesni_mb: support ZUC-EEA3/EIA3") Fixes: 8c835018de84 ("crypto/ipsec_mb: support ZUC-256 for aesni_mb") Cc: pablo.de.lara.guarch@intel.com Cc: stable@dpdk.org Signed-off-by: Pablo de Lara --- drivers/crypto/ipsec_mb/pmd_aesni_mb.c | 120 +++++++++++++++++-------- 1 file changed, 85 insertions(+), 35 deletions(-) diff --git a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c index a308d42ffa..eac8f1bd28 100644 --- a/drivers/crypto/ipsec_mb/pmd_aesni_mb.c +++ b/drivers/crypto/ipsec_mb/pmd_aesni_mb.c @@ -918,7 +918,9 @@ aesni_mb_set_docsis_sec_session_parameters( static inline uint64_t auth_start_offset(struct rte_crypto_op *op, struct aesni_mb_session *session, - uint32_t oop) + uint32_t oop, const uint32_t auth_offset, + const uint32_t cipher_offset, const uint32_t auth_length, + const uint32_t cipher_length) { struct rte_mbuf *m_src, *m_dst; uint8_t *p_src, *p_dst; @@ -927,7 +929,7 @@ auth_start_offset(struct rte_crypto_op *op, struct aesni_mb_session *session, /* Only cipher then hash needs special calculation. */ if (!oop || session->chain_order != IMB_ORDER_CIPHER_HASH) - return op->sym->auth.data.offset; + return auth_offset; m_src = op->sym->m_src; m_dst = op->sym->m_dst; @@ -935,24 +937,24 @@ auth_start_offset(struct rte_crypto_op *op, struct aesni_mb_session *session, p_src = rte_pktmbuf_mtod(m_src, uint8_t *); p_dst = rte_pktmbuf_mtod(m_dst, uint8_t *); u_src = (uintptr_t)p_src; - u_dst = (uintptr_t)p_dst + op->sym->auth.data.offset; + u_dst = (uintptr_t)p_dst + auth_offset; /** * Copy the content between cipher offset and auth offset for generating * correct digest. */ - if (op->sym->cipher.data.offset > op->sym->auth.data.offset) - memcpy(p_dst + op->sym->auth.data.offset, - p_src + op->sym->auth.data.offset, - op->sym->cipher.data.offset - - op->sym->auth.data.offset); + if (cipher_offset > auth_offset) + memcpy(p_dst + auth_offset, + p_src + auth_offset, + cipher_offset - + auth_offset); /** * Copy the content between (cipher offset + length) and (auth offset + * length) for generating correct digest */ - cipher_end = op->sym->cipher.data.offset + op->sym->cipher.data.length; - auth_end = op->sym->auth.data.offset + op->sym->auth.data.length; + cipher_end = cipher_offset + cipher_length; + auth_end = auth_offset + auth_length; if (cipher_end < auth_end) memcpy(p_dst + cipher_end, p_src + cipher_end, auth_end - cipher_end); @@ -1099,6 +1101,10 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp, struct aesni_mb_qp_data *qp_data = ipsec_mb_get_qp_private_data(qp); struct aesni_mb_session *session; uint32_t m_offset, oop; + uint32_t auth_off_in_bytes; + uint32_t ciph_off_in_bytes; + uint32_t auth_len_in_bytes; + uint32_t ciph_len_in_bytes; session = ipsec_mb_get_session_private(qp, op); if (session == NULL) { @@ -1207,6 +1213,7 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp, if (job->cipher_mode == IMB_CIPHER_ZUC_EEA3) { job->enc_keys = session->cipher.zuc_cipher_key; job->dec_keys = session->cipher.zuc_cipher_key; + m_offset >>= 3; } else if (job->cipher_mode == IMB_CIPHER_SNOW3G_UEA2_BITLEN) { job->enc_keys = &session->cipher.pKeySched_snow3g_cipher; m_offset = 0; @@ -1264,9 +1271,6 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp, switch (job->hash_alg) { case IMB_AUTH_AES_CCM: - job->cipher_start_src_offset_in_bytes = - op->sym->aead.data.offset; - job->msg_len_to_cipher_in_bytes = op->sym->aead.data.length; job->hash_start_src_offset_in_bytes = op->sym->aead.data.offset; job->msg_len_to_hash_in_bytes = op->sym->aead.data.length; @@ -1276,19 +1280,11 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp, case IMB_AUTH_AES_GMAC: if (session->cipher.mode == IMB_CIPHER_GCM) { - job->cipher_start_src_offset_in_bytes = - op->sym->aead.data.offset; job->hash_start_src_offset_in_bytes = op->sym->aead.data.offset; - job->msg_len_to_cipher_in_bytes = - op->sym->aead.data.length; job->msg_len_to_hash_in_bytes = op->sym->aead.data.length; } else { - job->cipher_start_src_offset_in_bytes = - op->sym->auth.data.offset; - job->hash_start_src_offset_in_bytes = - op->sym->auth.data.offset; job->msg_len_to_cipher_in_bytes = 0; job->msg_len_to_hash_in_bytes = 0; } @@ -1298,36 +1294,90 @@ set_mb_job_params(IMB_JOB *job, struct ipsec_mb_qp *qp, break; case IMB_AUTH_CHACHA20_POLY1305: - job->cipher_start_src_offset_in_bytes = - op->sym->aead.data.offset; job->hash_start_src_offset_in_bytes = op->sym->aead.data.offset; - job->msg_len_to_cipher_in_bytes = - op->sym->aead.data.length; job->msg_len_to_hash_in_bytes = op->sym->aead.data.length; job->iv = rte_crypto_op_ctod_offset(op, uint8_t *, session->iv.offset); break; - default: - /* For SNOW3G, length and offsets are already in bits */ - job->cipher_start_src_offset_in_bytes = - op->sym->cipher.data.offset; - job->msg_len_to_cipher_in_bytes = op->sym->cipher.data.length; + /* ZUC and SNOW3G require length in bits and offset in bytes */ + case IMB_AUTH_ZUC_EIA3_BITLEN: + case IMB_AUTH_ZUC256_EIA3_BITLEN: + case IMB_AUTH_SNOW3G_UIA2_BITLEN: + auth_off_in_bytes = op->sym->auth.data.offset >> 3; + ciph_off_in_bytes = op->sym->cipher.data.offset >> 3; + auth_len_in_bytes = op->sym->auth.data.length >> 3; + ciph_len_in_bytes = op->sym->cipher.data.length >> 3; + + job->hash_start_src_offset_in_bytes = auth_start_offset(op, + session, oop, auth_off_in_bytes, + ciph_off_in_bytes, auth_len_in_bytes, + ciph_len_in_bytes); + job->msg_len_to_hash_in_bits = op->sym->auth.data.length; + + job->iv = rte_crypto_op_ctod_offset(op, uint8_t *, + session->iv.offset); + break; + + /* KASUMI requires lengths and offset in bytes */ + case IMB_AUTH_KASUMI_UIA1: + auth_off_in_bytes = op->sym->auth.data.offset >> 3; + ciph_off_in_bytes = op->sym->cipher.data.offset >> 3; + auth_len_in_bytes = op->sym->auth.data.length >> 3; + ciph_len_in_bytes = op->sym->cipher.data.length >> 3; + + job->hash_start_src_offset_in_bytes = auth_start_offset(op, + session, oop, auth_off_in_bytes, + ciph_off_in_bytes, auth_len_in_bytes, + ciph_len_in_bytes); + job->msg_len_to_hash_in_bytes = auth_len_in_bytes; + + job->iv = rte_crypto_op_ctod_offset(op, uint8_t *, + session->iv.offset); + break; + + default: job->hash_start_src_offset_in_bytes = auth_start_offset(op, - session, oop); + session, oop, op->sym->auth.data.offset, + op->sym->cipher.data.offset, + op->sym->auth.data.length, op->sym->cipher.data.length); job->msg_len_to_hash_in_bytes = op->sym->auth.data.length; job->iv = rte_crypto_op_ctod_offset(op, uint8_t *, session->iv.offset); } - if (job->cipher_mode == IMB_CIPHER_ZUC_EEA3) - job->msg_len_to_cipher_in_bytes >>= 3; - else if (job->hash_alg == IMB_AUTH_KASUMI_UIA1) - job->msg_len_to_hash_in_bytes >>= 3; + switch (job->cipher_mode) { + /* ZUC requires length and offset in bytes */ + case IMB_CIPHER_ZUC_EEA3: + job->cipher_start_src_offset_in_bytes = + op->sym->cipher.data.offset >> 3; + job->msg_len_to_cipher_in_bytes = + op->sym->cipher.data.length >> 3; + break; + /* ZUC and SNOW3G require length and offset in bits */ + case IMB_CIPHER_SNOW3G_UEA2_BITLEN: + case IMB_CIPHER_KASUMI_UEA1_BITLEN: + job->cipher_start_src_offset_in_bits = + op->sym->cipher.data.offset; + job->msg_len_to_cipher_in_bits = + op->sym->cipher.data.length; + break; + case IMB_CIPHER_CCM: + case IMB_CIPHER_GCM: + case IMB_CIPHER_CHACHA20_POLY1305: + job->cipher_start_src_offset_in_bytes = + op->sym->aead.data.offset; + job->msg_len_to_cipher_in_bytes = op->sym->aead.data.length; + break; + default: + job->cipher_start_src_offset_in_bits = + op->sym->cipher.data.offset; + job->msg_len_to_cipher_in_bits = op->sym->cipher.data.length; + } /* Set user data to be crypto operation data struct */ job->user_data = op;