From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 38F845A005E for ; Fri, 25 Nov 2022 08:17:23 +0100 (CET) Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4NJR5C6F2tz4x1V; Fri, 25 Nov 2022 18:17:19 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=201602; t=1669360639; bh=fw/1OmZGMyY9UjiJ+OXUtpaI2VJOsvdtn2lQVlSrPf8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CsIAh6/Z6pi9eeutCT4kn0g9kXj6MrGAAxHlzTKhwYirfHnrRE4v96mtkN+qUw3Ui t67AEi5BwKYve6bQJMQFdNBLzEDMZ7fsz0GHlmwnx1lDwVwY2RqedGnsHlSazn5F7a xWWErC4j4sB7lJHCdRnCopQJcGk87TisbvRGYhnU= Date: Fri, 25 Nov 2022 18:01:51 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v2 01/16] udp: Also bind() connected ports for "splice" forwarding Message-ID: References: <20221124011659.1024901-1-david@gibson.dropbear.id.au> <20221124011659.1024901-2-david@gibson.dropbear.id.au> <20221125024751.36cbc4be@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="saHpn9jZgO1i7O8m" Content-Disposition: inline In-Reply-To: <20221125024751.36cbc4be@elisabeth> Message-ID-Hash: R7EH3PVQXBW4B56JS6KEN6TDNC5NJ7AT X-Message-ID-Hash: R7EH3PVQXBW4B56JS6KEN6TDNC5NJ7AT X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.3 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --saHpn9jZgO1i7O8m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 25, 2022 at 02:47:51AM +0100, Stefano Brivio wrote: > On Thu, 24 Nov 2022 12:16:44 +1100 > David Gibson wrote: >=20 > > pasta handles "spliced" port forwarding by resending datagrams received= on > > a bound socket in the init namespace to a connected socket in the guest > > namespace. This means there are actually three ports associated with e= ach > > "connection". First there's the source and destination ports of the > > originating datagram. That's also the destination port of the forwarded > > datagram, but the source port of the forwarded datagram is the kernel > > allocated bound address of the connected socket. > >=20 > > However, by bind()ing as well as connect()ing the forwarding socket we = can > > choose the source port of the forwarded datagrams. By choosing it to m= atch > > the original source port we remove that surprising third port number and > > no longer need to store port numbers in struct udp_splice_port. >=20 > If you wondered, I think the whole connect() with getsockname() thing > without a bind() came from the fundamental misconception I had that you > couldn't connect() a bound socket -- and I didn't quite think of > dropping connect() as you do in 3/16 anyway. >=20 > There's one minor problem this introduces: the source port of the > originating datagram now needs to be free in the init namespace. It's > still better than the alternative problem you fix in 16/16, though. You mean in the target namespace? Which could be init or otherwise depending on direction. That did occur to me, however, I believe the only way it would be not free is if we have a fixed port mapping occupying that port - in which case the problem goes away again in 8/16. > I'm wondering if we could, _once you're done with all this_ (it already > looks complicated enough), revisit the 'goto fail' in > udp_splice_connect() (now udp_splice_new()) when bind() fails, and just > proceed with an ephemeral port then. Oof... I'd rather not, because then we'd have to have somewhere to keep track of the original source port just for that unlikely edge case. > Also, I haven't tried, but I'm not sure if this introduces some kind of > DoS possibility: even if pasta forwards a single port, it should be > possible for a remote host to make pasta bind to a large amount of > non-ephemeral ports. Hm, yes, that's a point. > Maybe it would make sense to think of a limit on how many ports a > single peer could cause pasta to bind. Maybe, yes. > I'm not sure yet how we could track peers without a separate address > storage (even though keeping an LRU array should be feasible) -- the > simpler alternative, limiting bound ports by destination port, would > offer an even more convenient way to a DoS. >=20 > On the other hand, this is exceedingly minor I guess. We're binding > ports in the namespace after all, and we can reuse bound sockets. Right. I think this is something to address when and if it proves to be a problem in practice. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --saHpn9jZgO1i7O8m Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoULxWu4/Ws0dB+XtgypY4gEwYSIFAmOAaEgACgkQgypY4gEw YSLhvA//du6ndwdbCjD+hrgq9Ugb545sitAj2TmAJtisbs83xiNLP5jYPTvYJJ8H GpAzu5r8wecmhyo7MxBNnf3Und5Bm23O5NoNDt4iF/a8L5BxzLlYgi2QaYECAq4o 6sh0kpgdkotktEklvTINrfLuDdJ/LYIc64XiNZCFEyK7hRoyC5+dYWsiCHzKwBpF 363quuYbhiWgIvDBgCzNw9xbHnK9MzPE8trGAV8e2s/dDGAlVYViI7oZ+LIyF/Xb E9n5UZ1Sh2J9X6cnqggOym8NrifWNkMMNesPhiG77PrWnNwG46Nzpd28+x/su30b 1YHxy3gyQdC8Zc84FMxzI7uM9VVOtfdRWfPUXCpuNbg+8IFceFBYRKH8HeYK4Z/1 aUCb/GJlfHjuhJNsdqMNBnttugqZbyJNdBAYzy2P/V9K8l+Tig7hLqhN1rvyjASs H3k4lGNDlfvAVvhpy2rNnGn8oLVEaX/rDegcpK71it6Dsx+fihZT2bfPu89KkqV/ XZXTH3q/k32dz92TGBGfwxwKncFBozk2Vbqb/sAMvsLw1k5Xx1XGxxfVr2EuakJf uunu+oMyMi8GkzbuCRucM1QFwrMNCBn4s0R/naS9oDycAV0KPsdl+KgNQoxdYF/t 8JhHpfQMVVUXN5gpn2hpLKtPvHpwleKAL9q6qlX8USJyrtfC8uA= =jgEa -----END PGP SIGNATURE----- --saHpn9jZgO1i7O8m--