netdev - Re: [PATCH v2 13/17] net/mlx5e: Implement PSP Tx data path

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: <685ca856436a0_2a5da4294c9@willemb.c.googlers.com.notmuch>
Date: Wed, 25 Jun 2025 21:54:30 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Daniel Zahka <daniel.zahka@...il.com>, 
 Donald Hunter <donald.hunter@...il.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Paolo Abeni <pabeni@...hat.com>, 
 Simon Horman <horms@...nel.org>, 
 Jonathan Corbet <corbet@....net>, 
 Andrew Lunn <andrew+netdev@...n.ch>
Cc: Saeed Mahameed <saeedm@...dia.com>, 
 Leon Romanovsky <leon@...nel.org>, 
 Tariq Toukan <tariqt@...dia.com>, 
 Boris Pismenny <borisp@...dia.com>, 
 Kuniyuki Iwashima <kuniyu@...gle.com>, 
 Willem de Bruijn <willemb@...gle.com>, 
 David Ahern <dsahern@...nel.org>, 
 Neal Cardwell <ncardwell@...gle.com>, 
 Patrisious Haddad <phaddad@...dia.com>, 
 Raed Salem <raeds@...dia.com>, 
 Jianbo Liu <jianbol@...dia.com>, 
 Dragos Tatulea <dtatulea@...dia.com>, 
 Rahul Rameshbabu <rrameshbabu@...dia.com>, 
 Stanislav Fomichev <sdf@...ichev.me>, 
 Toke Høiland-Jørgensen <toke@...hat.com>, 
 Alexander Lobakin <aleksander.lobakin@...el.com>, 
 Jacob Keller <jacob.e.keller@...el.com>, 
 netdev@...r.kernel.org
Subject: Re: [PATCH v2 13/17] net/mlx5e: Implement PSP Tx data path

Daniel Zahka wrote:
> From: Raed Salem <raeds@...dia.com>
> 
> Setup PSP offload on Tx data path based on whether skb indicates that it is
> intended for PSP or not. Support driver side encapsulation of the UDP
> headers, PSP headers, and PSP trailer for the PSP traffic that will be
> encrypted by the NIC.
> 
> Signed-off-by: Raed Salem <raeds@...dia.com>
> Signed-off-by: Rahul Rameshbabu <rrameshbabu@...dia.com>
> Signed-off-by: Daniel Zahka <daniel.zahka@...il.com>

> +static void psp_write_headers(struct net *net, struct sk_buff *skb,
> +			      __be32 spi, u8 ver, unsigned int udp_len,
> +			      __be16 sport)
> +{
> +	struct udphdr *uh = udp_hdr(skb);
> +	struct psphdr *psph = (struct psphdr *)(uh + 1);
> +
> +	uh->dest = htons(PSP_DEFAULT_UDP_PORT);
> +	uh->source = udp_flow_src_port(net, skb, 0, 0, false);
> +	uh->check = 0;
> +	uh->len = htons(udp_len);
> +
> +	psph->nexthdr = IPPROTO_TCP;
> +	psph->hdrlen = PSP_HDRLEN_NOOPT;
> +	psph->crypt_offset = 0;
> +	psph->verfl = FIELD_PREP(PSPHDR_VERFL_VERSION, ver) |
> +		      FIELD_PREP(PSPHDR_VERFL_ONE, 1);
> +	psph->spi = spi;
> +	memset(&psph->iv, 0, sizeof(psph->iv));
> +}
> +
> +/* Encapsulate a TCP packet with PSP by adding the UDP+PSP headers and filling
> + * them in.
> + */
> +static bool psp_encapsulate(struct net *net, struct sk_buff *skb,
> +			    __be32 spi, u8 ver, __be16 sport)
> +{
> +	u32 network_len = skb_network_header_len(skb);
> +	u32 ethr_len = skb_mac_header_len(skb);
> +	u32 bufflen = ethr_len + network_len;
> +	struct ipv6hdr *ip6;
> +
> +	if (skb_cow_head(skb, PSP_ENCAP_HLEN))
> +		return false;
> +
> +	skb_push(skb, PSP_ENCAP_HLEN);
> +	skb->mac_header		-= PSP_ENCAP_HLEN;
> +	skb->network_header	-= PSP_ENCAP_HLEN;
> +	skb->transport_header	-= PSP_ENCAP_HLEN;
> +	memmove(skb->data, skb->data + PSP_ENCAP_HLEN, bufflen);
> +
> +	ip6 = ipv6_hdr(skb);
> +	skb_set_inner_ipproto(skb, IPPROTO_TCP);
> +	ip6->nexthdr = IPPROTO_UDP;
> +	be16_add_cpu(&ip6->payload_len, PSP_ENCAP_HLEN);
> +
> +	skb_set_inner_transport_header(skb, skb_transport_offset(skb) + PSP_ENCAP_HLEN);
> +	skb->encapsulation = 1;
> +	psp_write_headers(net, skb, spi, ver,
> +			  skb->len - skb_transport_offset(skb), sport);
> +
> +	return true;
> +}

It makes sense to do this in the driver.

But it would be good to from the start have this in a driver
independent location, as library functions that drivers can call.

Same for psp_rcv in patch 16.

Else, every driver is going to reimplement this logic.