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

[Daniel Zahka <daniel.zahka@gmail.com>]

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?