netdev - Re: [PATCH net-next v3 12/14] octeontx2-pf: ipsec: Process CPT metapackets

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: <20250712133950.GB721198@horms.kernel.org>
Date: Sat, 12 Jul 2025 14:39:50 +0100
From: Simon Horman <horms@...nel.org>
To: Tanmay Jagdale <tanmay@...vell.com>
Cc: davem@...emloft.net, leon@...nel.org, herbert@...dor.apana.org.au,
	sgoutham@...vell.com, bbhushan2@...vell.com,
	linux-crypto@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v3 12/14] octeontx2-pf: ipsec: Process CPT
 metapackets

On Fri, Jul 11, 2025 at 05:43:05PM +0530, Tanmay Jagdale wrote:
> CPT hardware forwards decrypted IPsec packets to NIX via the X2P bus
> as metapackets which are of 256 bytes in length. Each metapacket
> contains CPT_PARSE_HDR_S and initial bytes of the decrypted packet
> that helps NIX RX in classifying and submitting to CPU. Additionally,
> CPT also sets BIT(11) of the channel number to indicate that it's a
> 2nd pass packet from CPT.
> 
> Since the metapackets are not complete packets, they don't have to go
> through L3/L4 layer length and checksum verification so these are
> disabled via the NIX_LF_INLINE_RQ_CFG mailbox during IPsec initialization.
> 
> The CPT_PARSE_HDR_S contains a WQE pointer to the complete decrypted
> packet. Add code in the rx NAPI handler to parse the header and extract
> WQE pointer. Later, use this WQE pointer to construct the skb, set the
> XFRM packet mode flags to indicate successful decryption before submitting
> it to the network stack.
> 
> Signed-off-by: Tanmay Jagdale <tanmay@...vell.com>
> ---
> Changes in V3:
> - Updated cpt_parse_hdr_s structure to use __be64 type

...

> diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k_ipsec.h b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k_ipsec.h

...

> @@ -302,6 +303,41 @@ struct cpt_sg_s {
>  	u64 rsvd_63_50	: 14;
>  };
>  
> +/* CPT Parse Header Structure for Inbound packets */
> +struct cpt_parse_hdr_s {
> +	/* Word 0 */
> +	__be64 pkt_out     : 2;
> +	__be64 num_frags   : 3;
> +	__be64 pad_len     : 3;
> +	__be64 pkt_fmt     : 1;
> +	__be64 et_owr      : 1;
> +	__be64 reserved_53 : 1;
> +	__be64 reas_sts    : 4;
> +	__be64 err_sum     : 1;
> +	__be64 match_id    : 16;
> +	__be64 cookie      : 32;
> +
> +	/* Word 1 */
> +	__be64 wqe_ptr;
> +
> +	/* Word 2 */
> +	__be64 fi_offset   : 5;
> +	__be64 fi_pad      : 3;
> +	__be64 il3_off     : 8;
> +	__be64 pf_func     : 16;
> +	__be64 res_32_16   : 16;
> +	__be64 frag_age    : 16;
> +
> +	/* Word 3 */
> +	__be64 spi         : 32;
> +	__be64 res3_32_16  : 16;
> +	__be64 uc_ccode    : 8;
> +	__be64 hw_ccode    : 8;

Sparse complains about this and I'm not at all sure
how __be64 bitfields function on little endian systems.

I'd suggest using u64 members (not bitfields) and a combination of
FIELD_GET/FIELD_PREP, BITULL/GENMASK_ULL, and cpu_from_be64/be64_from_cpu.

> +
> +	/* Word 4 */
> +	__be64 misc;
> +};
> +

...

-- 
pw-bot: changes-requested