* [PATCH 1/2] examples/ipsec-secgw: fix SA salt endianness problem
[not found] <20240311024939.2523778-1-chaoyong.he@corigine.com>
@ 2024-03-11 2:49 ` Chaoyong He
2024-03-13 18:33 ` [EXTERNAL] " Akhil Goyal
2024-03-14 2:00 ` [PATCH v2] " Chaoyong He
2024-03-11 2:49 ` [PATCH 2/2] net/nfp: fix data " Chaoyong He
1 sibling, 2 replies; 8+ messages in thread
From: Chaoyong He @ 2024-03-11 2:49 UTC (permalink / raw)
To: dev; +Cc: oss-drivers, Shihong Wang, stable, Chaoyong He
From: Shihong Wang <shihong.wang@corigine.com>
The SA salt of struct ipsec_sa is a CPU-endian u32 variable, but it’s
value is stored in an array of encryption or authentication keys
according to big-endian. So it maybe need to convert the endianness
order to ensure that the value assigned to the SA salt is CPU-endian.
Fixes: 50d75cae2a2c ("examples/ipsec-secgw: initialize SA salt")
Fixes: 9413c3901f31 ("examples/ipsec-secgw: support additional algorithms")
Fixes: 501e9c226adf ("examples/ipsec-secgw: add AEAD parameters")
Cc: stable@dpdk.org
Signed-off-by: Shihong Wang <shihong.wang@corigine.com>
Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
---
examples/ipsec-secgw/sa.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index c4bac17cd7..4018b0558a 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -374,6 +374,7 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
uint32_t ti; /*token index*/
uint32_t *ri /*rule index*/;
struct ipsec_sa_cnt *sa_cnt;
+ rte_be32_t salt; /*big-endian salt*/
uint32_t cipher_algo_p = 0;
uint32_t auth_algo_p = 0;
uint32_t aead_algo_p = 0;
@@ -508,8 +509,9 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
if (algo->algo == RTE_CRYPTO_CIPHER_AES_CTR) {
key_len -= 4;
rule->cipher_key_len = key_len;
- memcpy(&rule->salt,
+ memcpy(&salt,
&rule->cipher_key[key_len], 4);
+ rule->salt = rte_be_to_cpu_32(salt);
}
cipher_algo_p = 1;
@@ -573,8 +575,9 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
key_len -= 4;
rule->auth_key_len = key_len;
rule->iv_len = algo->iv_len;
- memcpy(&rule->salt,
+ memcpy(&salt,
&rule->auth_key[key_len], 4);
+ rule->salt = rte_be_to_cpu_32(salt);
}
auth_algo_p = 1;
@@ -632,8 +635,9 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
key_len -= 4;
rule->cipher_key_len = key_len;
- memcpy(&rule->salt,
+ memcpy(&salt,
&rule->cipher_key[key_len], 4);
+ rule->salt = rte_be_to_cpu_32(salt);
aead_algo_p = 1;
continue;
--
2.39.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] net/nfp: fix data endianness problem
[not found] <20240311024939.2523778-1-chaoyong.he@corigine.com>
2024-03-11 2:49 ` [PATCH 1/2] examples/ipsec-secgw: fix SA salt endianness problem Chaoyong He
@ 2024-03-11 2:49 ` Chaoyong He
2024-03-13 15:39 ` Ferruh Yigit
1 sibling, 1 reply; 8+ messages in thread
From: Chaoyong He @ 2024-03-11 2:49 UTC (permalink / raw)
To: dev; +Cc: oss-drivers, Shihong Wang, stable, Chaoyong He
From: Shihong Wang <shihong.wang@corigine.com>
The algorithm key of the security framework is stored in the u8
array according to big-endian, and the driver algorithm key is
CPU-endian of u32, so it maybe need to convert the endianness order
to ensure that the value assigned to the driver is CPU-endian.
This patch removes the operation of converting IPsec Tx metadata
to big-endian to ensure that IPsec Tx metadata is CPU-endian.
Fixes: 547137405be7 ("net/nfp: initialize IPsec related content")
Fixes: 3d21da66c06b ("net/nfp: create security session")
Fixes: 310a1780581e ("net/nfp: support IPsec Rx and Tx offload")
Cc: stable@dpdk.org
Signed-off-by: Shihong Wang <shihong.wang@corigine.com>
Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
---
drivers/net/nfp/nfp_ipsec.c | 72 +++++++++++++++++++++++--------------
drivers/net/nfp/nfp_ipsec.h | 9 ++---
2 files changed, 47 insertions(+), 34 deletions(-)
diff --git a/drivers/net/nfp/nfp_ipsec.c b/drivers/net/nfp/nfp_ipsec.c
index 0b815fa983..8824533656 100644
--- a/drivers/net/nfp/nfp_ipsec.c
+++ b/drivers/net/nfp/nfp_ipsec.c
@@ -20,6 +20,7 @@
#include "nfp_rxtx.h"
#define NFP_UDP_ESP_PORT 4500
+#define NFP_ESP_IV_LENGTH 8
static const struct rte_cryptodev_capabilities nfp_crypto_caps[] = {
{
@@ -523,7 +524,8 @@ nfp_aesgcm_iv_update(struct ipsec_add_sa *cfg,
char *save;
char *iv_b;
char *iv_str;
- uint8_t *cfg_iv;
+ const rte_be32_t *iv_value;
+ uint8_t cfg_iv[NFP_ESP_IV_LENGTH];
iv_str = strdup(iv_string);
if (iv_str == NULL) {
@@ -531,8 +533,6 @@ nfp_aesgcm_iv_update(struct ipsec_add_sa *cfg,
return;
}
- cfg_iv = (uint8_t *)cfg->aesgcm_fields.iv;
-
for (i = 0; i < iv_len; i++) {
iv_b = strtok_r(i ? NULL : iv_str, ",", &save);
if (iv_b == NULL)
@@ -541,8 +541,9 @@ nfp_aesgcm_iv_update(struct ipsec_add_sa *cfg,
cfg_iv[i] = strtoul(iv_b, NULL, 0);
}
- *(uint32_t *)cfg_iv = rte_be_to_cpu_32(*(uint32_t *)cfg_iv);
- *(uint32_t *)&cfg_iv[4] = rte_be_to_cpu_32(*(uint32_t *)&cfg_iv[4]);
+ iv_value = (const rte_be32_t *)(cfg_iv);
+ cfg->aesgcm_fields.iv[0] = rte_be_to_cpu_32(iv_value[0]);
+ cfg->aesgcm_fields.iv[1] = rte_be_to_cpu_32(iv_value[1]);
free(iv_str);
}
@@ -583,7 +584,7 @@ nfp_aead_map(struct rte_eth_dev *eth_dev,
uint32_t offset;
uint32_t device_id;
const char *iv_str;
- const uint32_t *key;
+ const rte_be32_t *key;
struct nfp_net_hw *net_hw;
net_hw = eth_dev->data->dev_private;
@@ -633,7 +634,7 @@ nfp_aead_map(struct rte_eth_dev *eth_dev,
return -EINVAL;
}
- key = (const uint32_t *)(aead->key.data);
+ key = (const rte_be32_t *)(aead->key.data);
/*
* The CHACHA20's key order needs to be adjusted based on hardware design.
@@ -645,16 +646,22 @@ nfp_aead_map(struct rte_eth_dev *eth_dev,
for (i = 0; i < key_length / sizeof(cfg->cipher_key[0]); i++) {
index = (i + offset) % (key_length / sizeof(cfg->cipher_key[0]));
- cfg->cipher_key[index] = rte_cpu_to_be_32(*key++);
+ cfg->cipher_key[index] = rte_be_to_cpu_32(key[i]);
}
/*
- * The iv of the FW is equal to ESN by default. Reading the
- * iv of the configuration information is not supported.
+ * The iv of the FW is equal to ESN by default. Only the
+ * aead algorithm can offload the iv of configuration and
+ * the length of iv cannot be greater than NFP_ESP_IV_LENGTH.
*/
iv_str = getenv("ETH_SEC_IV_OVR");
if (iv_str != NULL) {
iv_len = aead->iv.length;
+ if (iv_len > NFP_ESP_IV_LENGTH) {
+ PMD_DRV_LOG(ERR, "Unsupported length of iv data");
+ return -EINVAL;
+ }
+
nfp_aesgcm_iv_update(cfg, iv_len, iv_str);
}
@@ -671,7 +678,7 @@ nfp_cipher_map(struct rte_eth_dev *eth_dev,
int ret;
uint32_t i;
uint32_t device_id;
- const uint32_t *key;
+ const rte_be32_t *key;
struct nfp_net_hw *net_hw;
net_hw = eth_dev->data->dev_private;
@@ -705,14 +712,14 @@ nfp_cipher_map(struct rte_eth_dev *eth_dev,
return -EINVAL;
}
- key = (const uint32_t *)(cipher->key.data);
+ key = (const rte_be32_t *)(cipher->key.data);
if (key_length > sizeof(cfg->cipher_key)) {
PMD_DRV_LOG(ERR, "Insufficient space for offloaded key");
return -EINVAL;
}
for (i = 0; i < key_length / sizeof(cfg->cipher_key[0]); i++)
- cfg->cipher_key[i] = rte_cpu_to_be_32(*key++);
+ cfg->cipher_key[i] = rte_be_to_cpu_32(key[i]);
return 0;
}
@@ -807,7 +814,7 @@ nfp_auth_map(struct rte_eth_dev *eth_dev,
uint32_t i;
uint8_t key_length;
uint32_t device_id;
- const uint32_t *key;
+ const rte_be32_t *key;
struct nfp_net_hw *net_hw;
if (digest_length == 0) {
@@ -854,7 +861,7 @@ nfp_auth_map(struct rte_eth_dev *eth_dev,
return -EINVAL;
}
- key = (const uint32_t *)(auth->key.data);
+ key = (const rte_be32_t *)(auth->key.data);
key_length = auth->key.length;
if (key_length > sizeof(cfg->auth_key)) {
PMD_DRV_LOG(ERR, "Insufficient space for offloaded auth key!");
@@ -862,7 +869,7 @@ nfp_auth_map(struct rte_eth_dev *eth_dev,
}
for (i = 0; i < key_length / sizeof(cfg->auth_key[0]); i++)
- cfg->auth_key[i] = rte_cpu_to_be_32(*key++);
+ cfg->auth_key[i] = rte_be_to_cpu_32(key[i]);
return 0;
}
@@ -902,7 +909,7 @@ nfp_crypto_msg_build(struct rte_eth_dev *eth_dev,
return ret;
}
- cfg->aesgcm_fields.salt = rte_cpu_to_be_32(conf->ipsec.salt);
+ cfg->aesgcm_fields.salt = conf->ipsec.salt;
break;
case RTE_CRYPTO_SYM_XFORM_AUTH:
/* Only support Auth + Cipher for inbound */
@@ -967,7 +974,10 @@ nfp_ipsec_msg_build(struct rte_eth_dev *eth_dev,
struct rte_security_session_conf *conf,
struct nfp_ipsec_msg *msg)
{
+ int i;
int ret;
+ rte_be32_t *src_ip;
+ rte_be32_t *dst_ip;
struct ipsec_add_sa *cfg;
enum rte_security_ipsec_tunnel_type type;
@@ -1025,12 +1035,18 @@ nfp_ipsec_msg_build(struct rte_eth_dev *eth_dev,
type = conf->ipsec.tunnel.type;
cfg->ctrl_word.mode = NFP_IPSEC_MODE_TUNNEL;
if (type == RTE_SECURITY_IPSEC_TUNNEL_IPV4) {
- cfg->src_ip.v4 = conf->ipsec.tunnel.ipv4.src_ip;
- cfg->dst_ip.v4 = conf->ipsec.tunnel.ipv4.dst_ip;
+ src_ip = (rte_be32_t *)&conf->ipsec.tunnel.ipv4.src_ip.s_addr;
+ dst_ip = (rte_be32_t *)&conf->ipsec.tunnel.ipv4.dst_ip.s_addr;
+ cfg->src_ip[0] = rte_be_to_cpu_32(src_ip[0]);
+ cfg->dst_ip[0] = rte_be_to_cpu_32(dst_ip[0]);
cfg->ipv6 = 0;
} else if (type == RTE_SECURITY_IPSEC_TUNNEL_IPV6) {
- cfg->src_ip.v6 = conf->ipsec.tunnel.ipv6.src_addr;
- cfg->dst_ip.v6 = conf->ipsec.tunnel.ipv6.dst_addr;
+ src_ip = (rte_be32_t *)conf->ipsec.tunnel.ipv6.src_addr.s6_addr;
+ dst_ip = (rte_be32_t *)conf->ipsec.tunnel.ipv6.dst_addr.s6_addr;
+ for (i = 0; i < 4; i++) {
+ cfg->src_ip[i] = rte_be_to_cpu_32(src_ip[i]);
+ cfg->dst_ip[i] = rte_be_to_cpu_32(dst_ip[i]);
+ }
cfg->ipv6 = 1;
} else {
PMD_DRV_LOG(ERR, "Unsupported address family!");
@@ -1043,9 +1059,11 @@ nfp_ipsec_msg_build(struct rte_eth_dev *eth_dev,
cfg->ctrl_word.mode = NFP_IPSEC_MODE_TRANSPORT;
if (type == RTE_SECURITY_IPSEC_TUNNEL_IPV4) {
memset(&cfg->src_ip, 0, sizeof(cfg->src_ip));
+ memset(&cfg->dst_ip, 0, sizeof(cfg->dst_ip));
cfg->ipv6 = 0;
} else if (type == RTE_SECURITY_IPSEC_TUNNEL_IPV6) {
memset(&cfg->src_ip, 0, sizeof(cfg->src_ip));
+ memset(&cfg->dst_ip, 0, sizeof(cfg->dst_ip));
cfg->ipv6 = 1;
} else {
PMD_DRV_LOG(ERR, "Unsupported address family!");
@@ -1179,18 +1197,18 @@ nfp_security_set_pkt_metadata(void *device,
desc_md = RTE_MBUF_DYNFIELD(m, offset, struct nfp_tx_ipsec_desc_msg *);
if (priv_session->msg.ctrl_word.ext_seq != 0 && sqn != NULL) {
- desc_md->esn.low = rte_cpu_to_be_32(*sqn);
- desc_md->esn.hi = rte_cpu_to_be_32(*sqn >> 32);
+ desc_md->esn.low = (uint32_t)*sqn;
+ desc_md->esn.hi = (uint32_t)(*sqn >> 32);
} else if (priv_session->msg.ctrl_word.ext_seq != 0) {
- desc_md->esn.low = rte_cpu_to_be_32(priv_session->ipsec.esn.low);
- desc_md->esn.hi = rte_cpu_to_be_32(priv_session->ipsec.esn.hi);
+ desc_md->esn.low = priv_session->ipsec.esn.low;
+ desc_md->esn.hi = priv_session->ipsec.esn.hi;
} else {
- desc_md->esn.low = rte_cpu_to_be_32(priv_session->ipsec.esn.value);
+ desc_md->esn.low = priv_session->ipsec.esn.low;
desc_md->esn.hi = 0;
}
desc_md->enc = 1;
- desc_md->sa_idx = rte_cpu_to_be_32(priv_session->sa_index);
+ desc_md->sa_idx = priv_session->sa_index;
}
return 0;
diff --git a/drivers/net/nfp/nfp_ipsec.h b/drivers/net/nfp/nfp_ipsec.h
index d7a729398a..f7c4f3f225 100644
--- a/drivers/net/nfp/nfp_ipsec.h
+++ b/drivers/net/nfp/nfp_ipsec.h
@@ -36,11 +36,6 @@ struct sa_ctrl_word {
uint32_t spare2 :1; /**< Must be set to 0 */
};
-union nfp_ip_addr {
- struct in6_addr v6;
- struct in_addr v4;
-};
-
struct ipsec_add_sa {
uint32_t cipher_key[8]; /**< Cipher Key */
union {
@@ -60,8 +55,8 @@ struct ipsec_add_sa {
uint8_t spare1;
uint32_t soft_byte_cnt; /**< Soft lifetime byte count */
uint32_t hard_byte_cnt; /**< Hard lifetime byte count */
- union nfp_ip_addr src_ip; /**< Src IP addr */
- union nfp_ip_addr dst_ip; /**< Dst IP addr */
+ uint32_t src_ip[4]; /**< Src IP addr */
+ uint32_t dst_ip[4]; /**< Dst IP addr */
uint16_t natt_dst_port; /**< NAT-T UDP Header dst port */
uint16_t natt_src_port; /**< NAT-T UDP Header src port */
uint32_t soft_lifetime_limit; /**< Soft lifetime time limit */
--
2.39.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] net/nfp: fix data endianness problem
2024-03-11 2:49 ` [PATCH 2/2] net/nfp: fix data " Chaoyong He
@ 2024-03-13 15:39 ` Ferruh Yigit
0 siblings, 0 replies; 8+ messages in thread
From: Ferruh Yigit @ 2024-03-13 15:39 UTC (permalink / raw)
To: Chaoyong He, dev; +Cc: oss-drivers, Shihong Wang, stable
On 3/11/2024 2:49 AM, Chaoyong He wrote:
> From: Shihong Wang <shihong.wang@corigine.com>
>
> The algorithm key of the security framework is stored in the u8
> array according to big-endian, and the driver algorithm key is
> CPU-endian of u32, so it maybe need to convert the endianness order
> to ensure that the value assigned to the driver is CPU-endian.
>
> This patch removes the operation of converting IPsec Tx metadata
> to big-endian to ensure that IPsec Tx metadata is CPU-endian.
>
> Fixes: 547137405be7 ("net/nfp: initialize IPsec related content")
> Fixes: 3d21da66c06b ("net/nfp: create security session")
> Fixes: 310a1780581e ("net/nfp: support IPsec Rx and Tx offload")
> Cc: stable@dpdk.org
>
> Signed-off-by: Shihong Wang <shihong.wang@corigine.com>
> Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
>
Applied to dpdk-next-net/main, thanks.
(not the set, just this patch)
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [EXTERNAL] [PATCH 1/2] examples/ipsec-secgw: fix SA salt endianness problem
2024-03-11 2:49 ` [PATCH 1/2] examples/ipsec-secgw: fix SA salt endianness problem Chaoyong He
@ 2024-03-13 18:33 ` Akhil Goyal
2024-03-14 1:41 ` Chaoyong He
2024-03-14 2:00 ` [PATCH v2] " Chaoyong He
1 sibling, 1 reply; 8+ messages in thread
From: Akhil Goyal @ 2024-03-13 18:33 UTC (permalink / raw)
To: Chaoyong He, dev; +Cc: oss-drivers, Shihong Wang, stable
> Subject: [EXTERNAL] [PATCH 1/2] examples/ipsec-secgw: fix SA salt endianness
> problem
> From: Shihong Wang <shihong.wang@corigine.com>
>
> The SA salt of struct ipsec_sa is a CPU-endian u32 variable, but it’s
> value is stored in an array of encryption or authentication keys
> according to big-endian. So it maybe need to convert the endianness
> order to ensure that the value assigned to the SA salt is CPU-endian.
>
> Fixes: 50d75cae2a2c ("examples/ipsec-secgw: initialize SA salt")
> Fixes: 9413c3901f31 ("examples/ipsec-secgw: support additional algorithms")
> Fixes: 501e9c226adf ("examples/ipsec-secgw: add AEAD parameters")
> Cc: stable@dpdk.org
>
> Signed-off-by: Shihong Wang <shihong.wang@corigine.com>
> Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
> ---
> examples/ipsec-secgw/sa.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
> index c4bac17cd7..4018b0558a 100644
> --- a/examples/ipsec-secgw/sa.c
> +++ b/examples/ipsec-secgw/sa.c
> @@ -374,6 +374,7 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
> uint32_t ti; /*token index*/
> uint32_t *ri /*rule index*/;
> struct ipsec_sa_cnt *sa_cnt;
> + rte_be32_t salt; /*big-endian salt*/
> uint32_t cipher_algo_p = 0;
> uint32_t auth_algo_p = 0;
> uint32_t aead_algo_p = 0;
> @@ -508,8 +509,9 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
> if (algo->algo == RTE_CRYPTO_CIPHER_AES_CTR) {
> key_len -= 4;
> rule->cipher_key_len = key_len;
> - memcpy(&rule->salt,
> + memcpy(&salt,
> &rule->cipher_key[key_len], 4);
> + rule->salt = rte_be_to_cpu_32(salt);
> }
>
> cipher_algo_p = 1;
> @@ -573,8 +575,9 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
> key_len -= 4;
> rule->auth_key_len = key_len;
> rule->iv_len = algo->iv_len;
> - memcpy(&rule->salt,
> + memcpy(&salt,
> &rule->auth_key[key_len], 4);
> + rule->salt = rte_be_to_cpu_32(salt);
> }
>
> auth_algo_p = 1;
> @@ -632,8 +635,9 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
>
> key_len -= 4;
> rule->cipher_key_len = key_len;
> - memcpy(&rule->salt,
> + memcpy(&salt,
> &rule->cipher_key[key_len], 4);
Can you put the memcpy call in a single line?
> + rule->salt = rte_be_to_cpu_32(salt);
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [EXTERNAL] [PATCH 1/2] examples/ipsec-secgw: fix SA salt endianness problem
2024-03-13 18:33 ` [EXTERNAL] " Akhil Goyal
@ 2024-03-14 1:41 ` Chaoyong He
0 siblings, 0 replies; 8+ messages in thread
From: Chaoyong He @ 2024-03-14 1:41 UTC (permalink / raw)
To: Akhil Goyal, dev; +Cc: oss-drivers, Shihong Wang, stable
> > Subject: [EXTERNAL] [PATCH 1/2] examples/ipsec-secgw: fix SA salt
> > endianness problem
> > From: Shihong Wang <shihong.wang@corigine.com>
> >
> > The SA salt of struct ipsec_sa is a CPU-endian u32 variable, but it’s
> > value is stored in an array of encryption or authentication keys
> > according to big-endian. So it maybe need to convert the endianness
> > order to ensure that the value assigned to the SA salt is CPU-endian.
> >
> > Fixes: 50d75cae2a2c ("examples/ipsec-secgw: initialize SA salt")
> > Fixes: 9413c3901f31 ("examples/ipsec-secgw: support additional
> > algorithms")
> > Fixes: 501e9c226adf ("examples/ipsec-secgw: add AEAD parameters")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Shihong Wang <shihong.wang@corigine.com>
> > Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
> > ---
> > examples/ipsec-secgw/sa.c | 10 +++++++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
> > index c4bac17cd7..4018b0558a 100644
> > --- a/examples/ipsec-secgw/sa.c
> > +++ b/examples/ipsec-secgw/sa.c
> > @@ -374,6 +374,7 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
> > uint32_t ti; /*token index*/
> > uint32_t *ri /*rule index*/;
> > struct ipsec_sa_cnt *sa_cnt;
> > + rte_be32_t salt; /*big-endian salt*/
> > uint32_t cipher_algo_p = 0;
> > uint32_t auth_algo_p = 0;
> > uint32_t aead_algo_p = 0;
> > @@ -508,8 +509,9 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
> > if (algo->algo == RTE_CRYPTO_CIPHER_AES_CTR) {
> > key_len -= 4;
> > rule->cipher_key_len = key_len;
> > - memcpy(&rule->salt,
> > + memcpy(&salt,
> > &rule->cipher_key[key_len], 4);
> > + rule->salt = rte_be_to_cpu_32(salt);
> > }
> >
> > cipher_algo_p = 1;
> > @@ -573,8 +575,9 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
> > key_len -= 4;
> > rule->auth_key_len = key_len;
> > rule->iv_len = algo->iv_len;
> > - memcpy(&rule->salt,
> > + memcpy(&salt,
> > &rule->auth_key[key_len], 4);
> > + rule->salt = rte_be_to_cpu_32(salt);
> > }
> >
> > auth_algo_p = 1;
> > @@ -632,8 +635,9 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
> >
> > key_len -= 4;
> > rule->cipher_key_len = key_len;
> > - memcpy(&rule->salt,
> > + memcpy(&salt,
> > &rule->cipher_key[key_len], 4);
> Can you put the memcpy call in a single line?
Okay, no problem.
I will send a v2 patch to fix that, thanks.
>
> > + rule->salt = rte_be_to_cpu_32(salt);
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] examples/ipsec-secgw: fix SA salt endianness problem
2024-03-11 2:49 ` [PATCH 1/2] examples/ipsec-secgw: fix SA salt endianness problem Chaoyong He
2024-03-13 18:33 ` [EXTERNAL] " Akhil Goyal
@ 2024-03-14 2:00 ` Chaoyong He
2024-03-14 18:17 ` [EXTERNAL] " Akhil Goyal
1 sibling, 1 reply; 8+ messages in thread
From: Chaoyong He @ 2024-03-14 2:00 UTC (permalink / raw)
To: dev; +Cc: oss-drivers, Shihong Wang, stable, Chaoyong He
From: Shihong Wang <shihong.wang@corigine.com>
The SA salt of struct ipsec_sa is a CPU-endian u32 variable, but it’s
value is stored in an array of encryption or authentication keys
according to big-endian. So it maybe need to convert the endianness
order to ensure that the value assigned to the SA salt is CPU-endian.
Fixes: 50d75cae2a2c ("examples/ipsec-secgw: initialize SA salt")
Fixes: 9413c3901f31 ("examples/ipsec-secgw: support additional algorithms")
Fixes: 501e9c226adf ("examples/ipsec-secgw: add AEAD parameters")
Cc: stable@dpdk.org
Signed-off-by: Shihong Wang <shihong.wang@corigine.com>
Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
---
v2:
* Put the 'memcpy()' call in a singal line as the review comment.
---
examples/ipsec-secgw/sa.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index c4bac17cd7..8aa9aca739 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -374,6 +374,7 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
uint32_t ti; /*token index*/
uint32_t *ri /*rule index*/;
struct ipsec_sa_cnt *sa_cnt;
+ rte_be32_t salt; /*big-endian salt*/
uint32_t cipher_algo_p = 0;
uint32_t auth_algo_p = 0;
uint32_t aead_algo_p = 0;
@@ -508,8 +509,8 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
if (algo->algo == RTE_CRYPTO_CIPHER_AES_CTR) {
key_len -= 4;
rule->cipher_key_len = key_len;
- memcpy(&rule->salt,
- &rule->cipher_key[key_len], 4);
+ memcpy(&salt, &rule->cipher_key[key_len], 4);
+ rule->salt = rte_be_to_cpu_32(salt);
}
cipher_algo_p = 1;
@@ -573,8 +574,8 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
key_len -= 4;
rule->auth_key_len = key_len;
rule->iv_len = algo->iv_len;
- memcpy(&rule->salt,
- &rule->auth_key[key_len], 4);
+ memcpy(&salt, &rule->auth_key[key_len], 4);
+ rule->salt = rte_be_to_cpu_32(salt);
}
auth_algo_p = 1;
@@ -632,8 +633,8 @@ parse_sa_tokens(char **tokens, uint32_t n_tokens,
key_len -= 4;
rule->cipher_key_len = key_len;
- memcpy(&rule->salt,
- &rule->cipher_key[key_len], 4);
+ memcpy(&salt, &rule->cipher_key[key_len], 4);
+ rule->salt = rte_be_to_cpu_32(salt);
aead_algo_p = 1;
continue;
--
2.39.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix SA salt endianness problem
2024-03-14 2:00 ` [PATCH v2] " Chaoyong He
@ 2024-03-14 18:17 ` Akhil Goyal
2024-03-14 19:11 ` Akhil Goyal
0 siblings, 1 reply; 8+ messages in thread
From: Akhil Goyal @ 2024-03-14 18:17 UTC (permalink / raw)
To: Chaoyong He, dev; +Cc: oss-drivers, Shihong Wang, stable
> From: Shihong Wang <shihong.wang@corigine.com>
>
> The SA salt of struct ipsec_sa is a CPU-endian u32 variable, but it’s
> value is stored in an array of encryption or authentication keys
> according to big-endian. So it maybe need to convert the endianness
> order to ensure that the value assigned to the SA salt is CPU-endian.
>
> Fixes: 50d75cae2a2c ("examples/ipsec-secgw: initialize SA salt")
> Fixes: 9413c3901f31 ("examples/ipsec-secgw: support additional algorithms")
> Fixes: 501e9c226adf ("examples/ipsec-secgw: add AEAD parameters")
> Cc: stable@dpdk.org
>
> Signed-off-by: Shihong Wang <shihong.wang@corigine.com>
> Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
>
Acked-by: Akhil Goyal <gakhil@marvell.com>
Applied to dpdk-next-crypto
Thanks
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix SA salt endianness problem
2024-03-14 18:17 ` [EXTERNAL] " Akhil Goyal
@ 2024-03-14 19:11 ` Akhil Goyal
0 siblings, 0 replies; 8+ messages in thread
From: Akhil Goyal @ 2024-03-14 19:11 UTC (permalink / raw)
To: Akhil Goyal, Chaoyong He, dev; +Cc: oss-drivers, Shihong Wang, stable
> Subject: RE: [EXTERNAL] [PATCH v2] examples/ipsec-secgw: fix SA salt
> endianness problem
>
> > From: Shihong Wang <shihong.wang@corigine.com>
> >
> > The SA salt of struct ipsec_sa is a CPU-endian u32 variable, but it’s
> > value is stored in an array of encryption or authentication keys
> > according to big-endian. So it maybe need to convert the endianness
> > order to ensure that the value assigned to the SA salt is CPU-endian.
> >
> > Fixes: 50d75cae2a2c ("examples/ipsec-secgw: initialize SA salt")
> > Fixes: 9413c3901f31 ("examples/ipsec-secgw: support additional algorithms")
> > Fixes: 501e9c226adf ("examples/ipsec-secgw: add AEAD parameters")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Shihong Wang <shihong.wang@corigine.com>
> > Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
> >
> Acked-by: Akhil Goyal <gakhil@marvell.com>
>
> Applied to dpdk-next-crypto
The patch is pulled back from dpdk-next-crypto.
This change may cause all the PMDs to fail these cases.
Would need acks from PMDs.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-03-14 19:12 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20240311024939.2523778-1-chaoyong.he@corigine.com>
2024-03-11 2:49 ` [PATCH 1/2] examples/ipsec-secgw: fix SA salt endianness problem Chaoyong He
2024-03-13 18:33 ` [EXTERNAL] " Akhil Goyal
2024-03-14 1:41 ` Chaoyong He
2024-03-14 2:00 ` [PATCH v2] " Chaoyong He
2024-03-14 18:17 ` [EXTERNAL] " Akhil Goyal
2024-03-14 19:11 ` Akhil Goyal
2024-03-11 2:49 ` [PATCH 2/2] net/nfp: fix data " Chaoyong He
2024-03-13 15:39 ` Ferruh Yigit
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).