netdev - Re: [PATCH v1 net-next 6/7] af_unix: Introduce SO

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAVpQUD1Exoz6iY-Bzst5EWD6Oh0z_adQ_R4QdUjad+WykWfiA@mail.gmail.com>
Date: Sun, 6 Jul 2025 12:21:05 -0700
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v1 net-next 6/7] af_unix: Introduce SO_INQ.

On Sun, Jul 6, 2025 at 7:02 AM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> Kuniyuki Iwashima wrote:
> > We have an application that uses almost the same code for TCP and
> > AF_UNIX (SOCK_STREAM).
> >
> > TCP can use TCP_INQ, but AF_UNIX doesn't have it and requires an
> > extra syscall, ioctl(SIOCINQ) or getsockopt(SO_MEMINFO) as an
> > alternative.
> >
> > Let's introduce the generic version of TCP_INQ.
> >
> > If SO_INQ is enabled, recvmsg() will put a cmsg of SCM_INQ that
> > contains the exact value of ioctl(SIOCINQ).  The cmsg is also
> > included when msg->msg_get_inq is non-zero to make sockets
> > io_uring-friendly.
> >
> > Note that SOCK_CUSTOM_SOCKOPT is flagged only for SOCK_STREAM to
> > override setsockopt() for SOL_SOCKET.
> >
> > By having the flag in struct unix_sock, instead of struct sock, we
> > can later add SO_INQ support for TCP and reuse tcp_sk(sk)->recvmsg_inq.
> >
> > Note also that supporting custom getsockopt() for SOL_SOCKET will need
> > preparation for other SOCK_CUSTOM_SOCKOPT users (UDP, vsock, MPTCP).
> >
> > Signed-off-by: Kuniyuki Iwashima <kuniyu@...gle.com>
>
> Reviewed-by: Willem de Bruijn <willemb@...gle.com>
>
> > +static int unix_setsockopt(struct socket *sock, int level, int optname,
> > +                        sockptr_t optval, unsigned int optlen)
> > +{
> > +     struct unix_sock *u = unix_sk(sock->sk);
> > +     struct sock *sk = sock->sk;
> > +     int val;
> > +
> > +     if (level != SOL_SOCKET)
> > +             return -EOPNOTSUPP;
> > +
> > +     if (!unix_custom_sockopt(optname))
> > +             return sock_setsockopt(sock, level, optname, optval, optlen);
> > +
> > +     if (optlen != sizeof(int))
> > +             return -EINVAL;
> > +
> > +     if (copy_from_sockptr(&val, optval, sizeof(val)))
> > +             return -EFAULT;
> > +
> > +     switch (optname) {
> > +     case SO_INQ:
> > +             if (sk->sk_type != SOCK_STREAM)
> > +                     return -EINVAL;
>
> Sanity check, but technically not needed as SOCK_CUSTOM_SOCKOPT is
> only set for SOCK_STREAM?

Yes, I planned to move other AF_UNIX specific options and reuse
unix_setsockopt() for DGRAM and SEQPACKET.


>
> > +
> > +             if (val > 1 || val < 0)
> > +                     return -EINVAL;
> > +
> > +             WRITE_ONCE(u->recvmsg_inq, val);
> > +             break;
> > +     default:
> > +             return -ENOPROTOOPT;
> > +     }
> > +
> > +     return 0;
> > +}
> > +
>