linux-kernel - Re: [net-next PATCH v1 13/15] octeontx2-pf: ipsec: Manage NPC rules and SPI-to-SA table entries

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250507155814.GG3339421@horms.kernel.org>
Date: Wed, 7 May 2025 16:58:14 +0100
From: Simon Horman <horms@...nel.org>
To: Tanmay Jagdale <tanmay@...vell.com>
Cc: bbrezillon@...nel.org, arno@...isbad.org, schalla@...vell.com,
	herbert@...dor.apana.org.au, davem@...emloft.net,
	sgoutham@...vell.com, lcherian@...vell.com, gakula@...vell.com,
	jerinj@...vell.com, hkelam@...vell.com, sbhatta@...vell.com,
	andrew+netdev@...n.ch, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, bbhushan2@...vell.com, bhelgaas@...gle.com,
	pstanner@...hat.com, gregkh@...uxfoundation.org,
	peterz@...radead.org, linux@...blig.org,
	krzysztof.kozlowski@...aro.org, giovanni.cabiddu@...el.com,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, rkannoth@...vell.com, sumang@...vell.com,
	gcherian@...vell.com
Subject: Re: [net-next PATCH v1 13/15] octeontx2-pf: ipsec: Manage NPC rules
 and SPI-to-SA table entries

On Fri, May 02, 2025 at 06:49:54PM +0530, Tanmay Jagdale wrote:
> NPC rule for IPsec flows
> ------------------------
> Incoming IPsec packets are first classified for hardware fastpath
> processing in the NPC block. Hence, allocate an MCAM entry in NPC
> using the MCAM_ALLOC_ENTRY mailbox to add a rule for IPsec flow
> classification.
> 
> Then, install an NPC rule at this entry for packet classification
> based on ESP header and SPI value with match action as UCAST_IPSEC.
> Also, these packets need to be directed to the dedicated receive
> queue so provide the RQ index as part of NPC_INSTALL_FLOW mailbox.
> Add a function to delete NPC rule as well.
> 
> SPI-to-SA match table
> ---------------------
> NIX RX maintains a common hash table for matching the SPI value from
> in ESP packet to the SA index associated with it. This table has 2K entries
> with 4 ways. When a packet is received with action as UCAST_IPSEC, NIXRX
> uses the SPI from the packet header to perform lookup in the SPI-to-SA
> hash table. This lookup, if successful, returns an SA index that is used
> by NIXRX to calculate the exact SA context address and programs it in
> the CPT_INST_S before submitting the packet to CPT for decryption.
> 
> Add functions to install the delete an entry from this table via the
> NIX_SPI_TO_SA_ADD and NIX_SPI_TO_SA_DELETE mailbox calls respectively.
> 
> When the RQs are changed at runtime via ethtool, RVU PF driver frees all
> the resources and goes through reinitialization with the new set of receive
> queues. As part of this flow, the UCAST_IPSEC NPC rules that were installed
> by the RVU PF/VF driver have to be reconfigured with the new RQ index.
> 
> So, delete the NPC rules when the interface is stopped via otx2_stop().
> When otx2_open() is called, re-install the NPC flow and re-initialize the
> SPI-to-SA table for every SA context that was previously installed.
> 
> Signed-off-by: Tanmay Jagdale <tanmay@...vell.com>
> ---
>  .../marvell/octeontx2/nic/cn10k_ipsec.c       | 201 ++++++++++++++++++
>  .../marvell/octeontx2/nic/cn10k_ipsec.h       |   7 +
>  .../ethernet/marvell/octeontx2/nic/otx2_pf.c  |   9 +
>  3 files changed, 217 insertions(+)
> 
> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k_ipsec.c b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k_ipsec.c

...

> +static int cn10k_inb_install_flow(struct otx2_nic *pfvf, struct xfrm_state *x,
> +				  struct cn10k_inb_sw_ctx_info *inb_ctx_info)
> +{
> +	struct npc_install_flow_req *req;
> +	int err;
> +
> +	mutex_lock(&pfvf->mbox.lock);
> +
> +	req = otx2_mbox_alloc_msg_npc_install_flow(&pfvf->mbox);
> +	if (!req) {
> +		err = -ENOMEM;
> +		goto out;
> +	}
> +
> +	req->entry = inb_ctx_info->npc_mcam_entry;
> +	req->features |= BIT(NPC_IPPROTO_ESP) | BIT(NPC_IPSEC_SPI) | BIT(NPC_DMAC);
> +	req->intf = NIX_INTF_RX;
> +	req->index = pfvf->ipsec.inb_ipsec_rq;
> +	req->match_id = 0xfeed;
> +	req->channel = pfvf->hw.rx_chan_base;
> +	req->op = NIX_RX_ACTIONOP_UCAST_IPSEC;
> +	req->set_cntr = 1;
> +	req->packet.spi = x->id.spi;
> +	req->mask.spi = 0xffffffff;

I realise that the value is isomorphic, but I would use the following
so that the rvalue has an endian annotation that matches the lvalue.

	req->mask.spi = cpu_to_be32(0xffffffff);

Flagged by Sparse.

> +
> +	/* Send message to AF */
> +	err = otx2_sync_mbox_msg(&pfvf->mbox);
> +out:
> +	mutex_unlock(&pfvf->mbox.lock);
> +	return err;
> +}

...

> +static int cn10k_inb_delete_spi_to_sa_match_entry(struct otx2_nic *pfvf,
> +						  struct cn10k_inb_sw_ctx_info *inb_ctx_info)

gcc-14.2.0 (at least) complains that cn10k_inb_delete_spi_to_sa_match_entry
is unused.

Likewise for cn10k_inb_delete_flow and cn10k_inb_delete_spi_to_sa_match_entry.

I'm unsure of the best way to address this but it would be nice
to avoid breaking build bisection for such a trivial reason.

Some ideas:
* Maybe it is possible to squash this and the last patch,
  or bring part of the last patch into this patch, or otherwise
  rearrange things to avoid this problem.
* Add temporary __maybe_unusd annotations.
  (I'd consider this a last resort.)

  ...