| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 12 Oct 2023 14:37:23 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Saeed Mahameed <saeed@...nel.org>, "David S. Miller"
<davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>
CC: Saeed Mahameed <saeedm@...dia.com>, <netdev@...r.kernel.org>, Tariq Toukan
<tariqt@...dia.com>, Leon Romanovsky <leonro@...dia.com>, Patrisious Haddad
<phaddad@...dia.com>
Subject: Re: [net-next V2 15/15] net/mlx5e: Allow IPsec soft/hard limits in
bytes
On 10/12/2023 12:27 PM, Saeed Mahameed wrote:
> From: Leon Romanovsky <leonro@...dia.com>
>
> Actually the mlx5 code already has needed support to allow users
> to configure soft/hard limits in bytes. It is possible due to the
> situation with TX path, where CX7 devices are missing hardware
> implementation to send events to the software, see commit b2f7b01d36a9
> ("net/mlx5e: Simulate missing IPsec TX limits hardware functionality").
>
> That software workaround is not limited to TX and works for bytes too.
> So relax the validation logic to not block soft/hard limits in bytes.
>
> Reviewed-by: Patrisious Haddad <phaddad@...dia.com>
> Signed-off-by: Leon Romanovsky <leonro@...dia.com>
> Signed-off-by: Saeed Mahameed <saeedm@...dia.com>
Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>
> ---
> .../mellanox/mlx5/core/en_accel/ipsec.c | 23 +++++++++++-------
> .../mellanox/mlx5/core/en_accel/ipsec_fs.c | 24 +++++++++++--------
> 2 files changed, 28 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
> index 7d4ceb9b9c16..257c41870f78 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
> @@ -56,7 +56,7 @@ static struct mlx5e_ipsec_pol_entry *to_ipsec_pol_entry(struct xfrm_policy *x)
> return (struct mlx5e_ipsec_pol_entry *)x->xdo.offload_handle;
> }
>
> -static void mlx5e_ipsec_handle_tx_limit(struct work_struct *_work)
> +static void mlx5e_ipsec_handle_sw_limits(struct work_struct *_work)
> {
> struct mlx5e_ipsec_dwork *dwork =
> container_of(_work, struct mlx5e_ipsec_dwork, dwork.work);
> @@ -486,9 +486,15 @@ static int mlx5e_xfrm_validate_state(struct mlx5_core_dev *mdev,
> return -EINVAL;
> }
>
> - if (x->lft.hard_byte_limit != XFRM_INF ||
> - x->lft.soft_byte_limit != XFRM_INF) {
> - NL_SET_ERR_MSG_MOD(extack, "Device doesn't support limits in bytes");
> + if (x->lft.soft_byte_limit >= x->lft.hard_byte_limit &&
> + x->lft.hard_byte_limit != XFRM_INF) {
> + /* XFRM stack doesn't prevent such configuration :(. */
> + NL_SET_ERR_MSG_MOD(extack, "Hard byte limit must be greater than soft one");
> + return -EINVAL;
> + }
> +
Seems like we should fix that? :D
> + if (!x->lft.soft_byte_limit || !x->lft.hard_byte_limit) {
> + NL_SET_ERR_MSG_MOD(extack, "Soft/hard byte limits can't be 0");
> return -EINVAL;
> }
>
> @@ -624,11 +630,10 @@ static int mlx5e_ipsec_create_dwork(struct mlx5e_ipsec_sa_entry *sa_entry)
> if (x->xso.type != XFRM_DEV_OFFLOAD_PACKET)
> return 0;
>
> - if (x->xso.dir != XFRM_DEV_OFFLOAD_OUT)
> - return 0;
> -
> if (x->lft.soft_packet_limit == XFRM_INF &&
> - x->lft.hard_packet_limit == XFRM_INF)
> + x->lft.hard_packet_limit == XFRM_INF &&
> + x->lft.soft_byte_limit == XFRM_INF &&
> + x->lft.hard_byte_limit == XFRM_INF)
> return 0;
>
> dwork = kzalloc(sizeof(*dwork), GFP_KERNEL);
> @@ -636,7 +641,7 @@ static int mlx5e_ipsec_create_dwork(struct mlx5e_ipsec_sa_entry *sa_entry)
> return -ENOMEM;
>
> dwork->sa_entry = sa_entry;
> - INIT_DELAYED_WORK(&dwork->dwork, mlx5e_ipsec_handle_tx_limit);
> + INIT_DELAYED_WORK(&dwork->dwork, mlx5e_ipsec_handle_sw_limits);
> sa_entry->dwork = dwork;
> return 0;
> }
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_fs.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_fs.c
> index 7dba4221993f..eda1cb528deb 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_fs.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec_fs.c
> @@ -1249,15 +1249,17 @@ static int rx_add_rule(struct mlx5e_ipsec_sa_entry *sa_entry)
> setup_fte_no_frags(spec);
> setup_fte_upper_proto_match(spec, &attrs->upspec);
>
> - if (rx != ipsec->rx_esw)
> - err = setup_modify_header(ipsec, attrs->type,
> - sa_entry->ipsec_obj_id | BIT(31),
> - XFRM_DEV_OFFLOAD_IN, &flow_act);
> - else
> - err = mlx5_esw_ipsec_rx_setup_modify_header(sa_entry, &flow_act);
> + if (!attrs->drop) {
> + if (rx != ipsec->rx_esw)
> + err = setup_modify_header(ipsec, attrs->type,
> + sa_entry->ipsec_obj_id | BIT(31),
> + XFRM_DEV_OFFLOAD_IN, &flow_act);
> + else
> + err = mlx5_esw_ipsec_rx_setup_modify_header(sa_entry, &flow_act);
>
> - if (err)
> - goto err_mod_header;
> + if (err)
> + goto err_mod_header;
> + }
>
> switch (attrs->type) {
> case XFRM_DEV_OFFLOAD_PACKET:
> @@ -1307,7 +1309,8 @@ static int rx_add_rule(struct mlx5e_ipsec_sa_entry *sa_entry)
> if (flow_act.pkt_reformat)
> mlx5_packet_reformat_dealloc(mdev, flow_act.pkt_reformat);
> err_pkt_reformat:
> - mlx5_modify_header_dealloc(mdev, flow_act.modify_hdr);
> + if (flow_act.modify_hdr)
> + mlx5_modify_header_dealloc(mdev, flow_act.modify_hdr);
> err_mod_header:
> kvfree(spec);
> err_alloc:
> @@ -1805,7 +1808,8 @@ void mlx5e_accel_ipsec_fs_del_rule(struct mlx5e_ipsec_sa_entry *sa_entry)
> return;
> }
>
> - mlx5_modify_header_dealloc(mdev, ipsec_rule->modify_hdr);
> + if (ipsec_rule->modify_hdr)
> + mlx5_modify_header_dealloc(mdev, ipsec_rule->modify_hdr);
> mlx5_esw_ipsec_rx_id_mapping_remove(sa_entry);
> rx_ft_put(sa_entry->ipsec, sa_entry->attrs.family, sa_entry->attrs.type);
> }
Powered by blists - more mailing lists