netdev - Re: [PATCH net-next v10 08/19] net: psp: add socket security association code

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: <a30deb61-92e9-445e-a3c0-5ba9dab52b72@gmail.com>
Date: Tue, 2 Sep 2025 22:58:44 -0400
From: Daniel Zahka <daniel.zahka@...il.com>
To: Paolo Abeni <pabeni@...hat.com>, Donald Hunter <donald.hunter@...il.com>,
 Jakub Kicinski <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.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>,
 Kiran Kella <kiran.kella@...adcom.com>,
 Jacob Keller <jacob.e.keller@...el.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v10 08/19] net: psp: add socket security
 association code

On 9/2/25 6:43 AM, Paolo Abeni wrote:
> On 8/28/25 6:29 PM, Daniel Zahka wrote:
>> +int psp_assoc_device_get_locked(const struct genl_split_ops *ops,
>> +				struct sk_buff *skb, struct genl_info *info)
>> +{
>> +	struct socket *socket;
>> +	struct psp_dev *psd;
>> +	struct nlattr *id;
>> +	int fd, err;
>> +
>> +	if (GENL_REQ_ATTR_CHECK(info, PSP_A_ASSOC_SOCK_FD))
>> +		return -EINVAL;
>> +
>> +	fd = nla_get_u32(info->attrs[PSP_A_ASSOC_SOCK_FD]);
>> +	socket = sockfd_lookup(fd, &err);
>> +	if (!socket)
>> +		return err;
>> +
>> +	if (!sk_is_tcp(socket->sk)) {
>> +		NL_SET_ERR_MSG_ATTR(info->extack,
>> +				    info->attrs[PSP_A_ASSOC_SOCK_FD],
>> +				    "Unsupported socket family and type");
>> +		err = -EOPNOTSUPP;
>> +		goto err_sock_put;
>> +	}
> It's not clear to me if a family check is required here. AFAICS the RX
> path is contrained to IPv6 only, as per spec, but the TX (NIC) allows
> even IPv4.
>
> What happens if the psp assoc is bound to an IPv4 socket? What if in
> case of ADDRFORM?

PSP transport mode with IPv4 as the l3 header is permitted by the spec. 
You are right that the series only really supports IPv6 as it is now, 
given how psp_dev_rcv() and psp_dev_encapsulate() are implemented. I 
will update both of these functions to support IPv4 in the next version.

I am a fairly ignorant to how IPV6_ADDRFORM works. Will this still be an 
issue if IPv4 is fully supported, or do we need to disallow this sockopt 
on psp sockets?