From nobody Thu Oct 13 10:48:27 2022 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mp5pm0gnjz4fgnC; Thu, 13 Oct 2022 10:48:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mp5pm05Mcz43PC; Thu, 13 Oct 2022 10:48:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1665658112; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q8tz6GuYAt+Y9uAnYSt5vo+uDyQWFETwiy/EcYZjPB4=; b=vB36qt3SDPsvWbg2QieJcyJs9IkA3UugU7RiTJY5Lvz5zLOAb0GYTVV6MIQiMhVauVPaHj BN1EogKhVtr+rTxpj92z9X93ieKp0NyhadJPGWRUJROWpqXIBLEhfaXyOPDghQoYiVI1Vx SoZ/ok6OBQirnPI3mxptZhcfWHiHe8lusFJocNub8FxdisfwyvHJC4c4/mMqwXJ78BmOsx VmCKHDvvnUWuW4q9DEBDbQ83lQeREYuLhpeCMOwoLExk6FrxRHJq3y709xEkB/YqwzWMiP osjFRw/uQzCOQFz0bkRVA+5p6s5Fe+cSoFTUTOrZGnWlJCbJ1nCojLAgX0eL8g== Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mp5pl3YKWz17tF; Thu, 13 Oct 2022 10:48:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: Date: Thu, 13 Oct 2022 13:48:27 +0300 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.3.2 Subject: UDP port re-use [Was: in_pcbbind_setup: wrong condition regarding INP_REUSEPORT ?] Content-Language: en-US From: Andriy Gapon To: "net@FreeBSD.org" , FreeBSD Current References: <896ee089-27ad-c98f-6bf9-4b05caf778fd@freebsd.org> <9037ac3d-8d8e-2d7d-cbdb-996a53613aca@FreeBSD.org> In-Reply-To: <9037ac3d-8d8e-2d7d-cbdb-996a53613aca@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1665658112; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q8tz6GuYAt+Y9uAnYSt5vo+uDyQWFETwiy/EcYZjPB4=; b=U9btPVK6IEv+s2dFh5a2a7E/csEOtkcvnmK548t2Z/FbZUtrl/3HfTYxCgJI87Jbz5BUhJ HFtW6KPSqcv6kmobPnXK94uFU3Do/C8t5YIT3jxxBwEJcsFcVGGSiYDbeJUdhbgS8g7fCh r/m3unB9nFz0rQyTabzboH6vQgCib6cobG1xVyqJ2Rm0jJPj3gEax0cvsZar4TTbXUPeF6 sq+D3Q0F8tcSJGwdW7rB/8ncXiUoo9vIH26HowoAZ9iT2UGwi4lqx3aWB2tBsOwPrX7pt3 1oYKkgMD50eNPmq+qYzAFXXeedOg5oAM8lBbASHxJLOgUhSVa0D/2PME4/Ei3Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1665658112; a=rsa-sha256; cv=none; b=vXVoGaguI/vGIoCnS/hZi7CLGsO/dhDfnH4jF3LjUr8RLxOE7Vw0M410ks/xFz3LkiqgJC T2GocxTFpJ0TCcLTYufZfJUhd24b3oqesX0APlxZaXG1RUmaKS+Uu8Y1Ne2R7QpM5Il7H4 cYyTN3A6xOgEIlcUrNtK78gfQQ8otNaCbbYWDZ2kvGDnohLRIj7KE+r1etzB5vYR4Vfsxw PBlyLX6pUd/bEUEjyLsQIW7Gw8CaTiCpDiYtgmoBnnRGi9gIhHmAwn46HP5iAsATEpHZtt FtK7ENdDJgJ+n7LtmrodbDSU7h5Aw+HODLoL53nmYeBt4sFNUERd2nSb0dUNfg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Do we have test cases or a document that can be a definitive guide to UDP port re-use on FreeBSD? Including effects of INP_REUSEADDR, INP_REUSEPORT and INP_REUSEPORT_LB socket options, socket addresses, socket credentials? I can find some descriptions on the internet, but they do not seem to be complete. The effect of addresses is under-described and I do not see any mention of credentials (UIDs). Is there a way to tell if some behavior is correct or not? Is it all in heads of people and in the change history? On 04/10/2022 14:46, Andriy Gapon wrote: > On 04/10/2022 14:37, Sean Bruno wrote: >> >> >> On 10/3/22 04:14, Andriy Gapon wrote: >>> >>> I must admit that the condition in question is fairly long and non-trivial >>> and I cannot decipher it, but these two lines look wrong to me: >>> >>>                                       (t->inp_flags2 & INP_REUSEPORT) || >>>                                       (t->inp_flags2 & INP_REUSEPORT_LB) == >>> 0) && >>> >>> I'd expect that the check would be symmetric with respect to INP_REUSEPORT >>> and INP_REUSEPORT_LB. >>> The problem seems to come from 1a43cff92a20d / r334719 / D11003. >>> >> >> I think you are pointing at this absurd conditional? >> >> https://cgit.freebsd.org/src/tree/sys/netinet/in_pcb.c#n1049 >> >> Besides the twisted logic, what problem are you trying to solve? > > Yes, that conditional. > I pointed out the part of it that does not make sense to me. > > Also, in my tests SO_REUSEPORT does not actually allow to share a port. > Test scenario: > - create a UDP socket > - setsockopt(SO_REUSEPORT) > - bind the socket to a port and wild card address > - success > - now repeat the previous steps with the same port *under a different user id* > - bind fails > > I wonder if the following would be a correct change. > > diff --git a/sys/netinet/in_pcb.c b/sys/netinet/in_pcb.c > index d9247f50d32b..f5e6e3932a96 100644 > --- a/sys/netinet/in_pcb.c > +++ b/sys/netinet/in_pcb.c > @@ -1003,6 +1003,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, > in_addr_t *laddrp, >      /* >       * XXX >       * This entire block sorely needs a rewrite. > +     * And a good comment describing the rationale behind the conditions. >       */ >                  if (t && >                      ((inp->inp_flags2 & INP_BINDMULTI) == 0) && > @@ -1011,8 +1012,7 @@ in_pcbbind_setup(struct inpcb *inp, struct sockaddr *nam, > in_addr_t *laddrp, >                       ntohl(t->inp_faddr.s_addr) == INADDR_ANY) && >                      (ntohl(sin->sin_addr.s_addr) != INADDR_ANY || >                       ntohl(t->inp_laddr.s_addr) != INADDR_ANY || > -                     (t->inp_flags2 & INP_REUSEPORT) || > -                     (t->inp_flags2 & INP_REUSEPORT_LB) == 0) && > +                     (t->inp_flags2 & (INP_REUSEPORT | INP_REUSEPORT_LB)) == 0) && >                      (inp->inp_cred->cr_uid != >                       t->inp_cred->cr_uid)) >                      return (EADDRINUSE); > -- Andriy Gapon