netdev - Re: [PATCHv4 net-next 0/2] net: enable udp v6 sockets receiving v4 packets with UDP GRO

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: <CADvbK_ePdoJRna81YwJUL5cqu1ST3W8J8kRqhbNVGdSse-3u1w@mail.gmail.com>
Date:   Wed, 3 Feb 2021 21:47:18 +0800
From:   Xin Long <lucien.xin@...il.com>
To:     David Howells <dhowells@...hat.com>
Cc:     network dev <netdev@...r.kernel.org>, davem <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Martin Varghese <martin.varghese@...ia.com>,
        Alexander Duyck <alexander.duyck@...il.com>,
        vfedorenko@...ek.ru
Subject: Re: [PATCHv4 net-next 0/2] net: enable udp v6 sockets receiving v4
 packets with UDP GRO

On Wed, Feb 3, 2021 at 5:14 PM David Howells <dhowells@...hat.com> wrote:
>
> Xin Long <lucien.xin@...il.com> wrote:
>
> > BTW, I'm also thinking to use udp_sock_create(), the only problem I can
> > see is it may not do bind() in rxrpc_open_socket(), is that true? or we
> > can actually bind to some address when a local address is not supplied?
>
> If a local address isn't explicitly bound to the AF_RXRPC socket, binding the
> UDP socket to a random local port is fine.  In fact, sometimes I want to
> explicitly bind an rxrpc server socket to a random port.  See fs/afs/rxrpc.c
> function afs_open_socket():
>
>         /* bind the callback manager's address to make this a server socket */
>         memset(&srx, 0, sizeof(srx));
>         srx.srx_family                  = AF_RXRPC;
>         srx.srx_service                 = CM_SERVICE;
>         srx.transport_type              = SOCK_DGRAM;
>         srx.transport_len               = sizeof(srx.transport.sin6);
>         srx.transport.sin6.sin6_family  = AF_INET6;
>         srx.transport.sin6.sin6_port    = htons(AFS_CM_PORT);
>         ...
>         ret = kernel_bind(socket, (struct sockaddr *) &srx, sizeof(srx));
>         if (ret == -EADDRINUSE) {
>                 srx.transport.sin6.sin6_port = 0;
>
>                 ^^^ That's hoping to get a random port bound.
>
>                 ret = kernel_bind(socket, (struct sockaddr *) &srx, sizeof(srx));
>         }
>         if (ret < 0)
>                 goto error_2;
>
> The client cache manager server socket here is used to receive notifications
> back from the fileserver.  There's a standard port (7001) for the service, but
> if that's in use, we can use any other port.  The fileserver grabs the source
> port from incoming RPC requests - and then uses that when sending 3rd-party
> change notifications back.
>
> If you could arrange for a random port to be assigned in such a case (and
> indicated back to the caller), that would be awesome.  Possibly I just don't
> need to actually use bind in this case.
>
The patch is attached (based on this patch):

+       udp_conf.family = srx->transport.family;
+       if (udp_conf.family == AF_INET) {
+               udp_conf.local_ip = srx->transport.sin.sin_addr;
+               udp_conf.local_udp_port = srx->transport.sin.sin_port;
+       } else {
+               udp_conf.local_ip6 = srx->transport.sin6.sin6_addr;
+               udp_conf.local_udp_port = srx->transport.sin6.sin6_port;
+       }
+       ret = udp_sock_create(net, &udp_conf, &local->socket);

I think this will work well. When the socket is not bound,
srx->transport.sin.sin(6)_addr/sin(6)_port are zero. It'll
bind to a random port in udp_sock_create().

BTW: do you have any testing for this?

Thanks.

Download attachment "0001-rxrpc-use-udp-tunnel-APIs-instead-of-open-code-in-rx.patch" of type "application/octet-stream" (4027 bytes)