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: <CAL+tcoAJic7sWergDhVqAvLLu2tto+b7A8FU_pkwLhq=9qCE1w@mail.gmail.com>
Date: Tue, 20 Aug 2024 08:53:53 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, 
	dsahern@...nel.org, ncardwell@...gle.com, netdev@...r.kernel.org, 
	Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next] tcp: change source port selection at bind() time

Hello Eric,

On Mon, Aug 19, 2024 at 11:45 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Fri, Aug 16, 2024 at 5:33 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> >
> > From: Jason Xing <kernelxing@...cent.com>
> >
> > This is a follow-up patch to an eariler commit 207184853dbd ("tcp/dccp:
> > change source port selection at connect() time").
> >
> > This patch extends the use of IP_LOCAL_PORT_RANGE option, so that we
> > don't need to iterate every two ports which means only favouring odd
> > number like the old days before 2016, which can be good for some
> > users who want to keep in consistency with IP_LOCAL_PORT_RANGE in
> > connect().
>
> Except that bind() with a port reservation is not as common as a connect().
> This is highly discouraged.
>
> See IP_BIND_ADDRESS_NO_PORT
>
> Can you provide a real use case ?
>
> I really feel like you are trying to push patches 'just because you can'...
>
> 'The old days' before 2016 were not very nice, we had P0 all the time
> because of port exhaustion.
> Since 2016 and IP_BIND_ADDRESS_NO_PORT I no longer have war rooms stories.

As you mentioned last night, the issues happening in connect() are
relatively more than in bind().

To be more concise, I would like to state 3 points to see if they are valid:
(1) Extending the option for bind() is the last puzzle of using an
older algorithm for some users. Since we have one in connect(), how
about adding it in bind() to provide for the people favouring the
older algorithm.
(2) This patch will not hurt any users like in Google as an example
which prefers odd/even port selection, which is, I admit, indeed more
advanced.
(3) This patch does not come out of thin air, but from some users who I contact.
?

In my opinion, using and adjusting to the new algorithm needs some
changes in applications. For some old applications, they still need
more time to keep pace with a more workable solution.

After considering it a whole night, I would like to push this tiny
feature into the upstream kernel, I wonder if you can help me review
it? Thanks in advance, Eric.

Thanks,
Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ