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] [day] [month] [year] [list]

Message-ID: <aHkR9xKzLmlT7RGF@optiplex>
Date: Thu, 17 Jul 2025 20:38:39 +0530
From: Tanmay Jagdale <tanmay@...vell.com>
To: Simon Horman <horms@...nel.org>
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

Hi Simon,

On 2025-07-12 at 19:09:50, Simon Horman (horms@...nel.org) wrote:
> 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.
Okay sure. I will switch to FIELD_GET/PREP mechanism in the next version.

With Regards,
Tanmay
> 
> > +
> > +	/* Word 4 */
> > +	__be64 misc;
> > +};
> > +
> 
> ...
> 
> -- 
> pw-bot: changes-requested