linux-kernel - Re: [PATCH net v3 1/2] net: tcp: lookup the best matched listen socket

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: <CADxym3bBVEKRNa790CchSyH-WPeXmv9tjTxtmYyJamQv357zKg@mail.gmail.com>
Date: Wed, 13 Aug 2025 20:54:48 +0800
From: Menglong Dong <menglong8.dong@...il.com>
To: Jason Xing <kerneljasonxing@...il.com>, kuniyu@...gle.com
Cc: edumazet@...gle.com, ncardwell@...gle.com, davem@...emloft.net, 
	dsahern@...nel.org, kuba@...nel.org, pabeni@...hat.com, horms@...nel.org, 
	shuah@...nel.org, kraig@...gle.com, linux-kernel@...r.kernel.org, 
	netdev@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net v3 1/2] net: tcp: lookup the best matched listen socket

On Sun, Aug 3, 2025 at 4:32 PM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> On Sun, Aug 3, 2025 at 12:00 PM Menglong Dong <menglong8.dong@...il.com> wrote:
> >
> > On Sun, Aug 3, 2025 at 10:54 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> > >
> > > On Sun, Aug 3, 2025 at 9:59 AM Menglong Dong <menglong8.dong@...il.com> wrote:
> > > >
> > > > On Sat, Aug 2, 2025 at 9:06 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > > >
[......]
> > >
> > > I'm trying to picture what the usage can be in the userland as you
> > > pointed out in the MD5 case. As to the client side, it seems weird
> > > since it cannot detect and know the priority of the other side where a
> > > few sockets listen on the same address and port.
> >
> > For the server side, it needs to add all the clients information
> > with the TCP_MD5SIG option. For socket1 that binded on the
> > eth0, it will add all the client addresses that come from eth0 to the
> > socket1 with TCP_MD5SIG. So the server knows the clients.
>
> Right, but I meant the _client_ side doesn't know the details of the
> other side, that is to say, the server side needs to keep sure the
> client server easily connects to your preferred listener regardless of
> what the selection algorithm looks like. In terms of what you
> depicted, I see your point. One question is if the kernel or API
> provides any rules and instructions to the users that on the server
> side the sk1 must be selected in your case? Is it possible for other
> cases where the sk2 is the preferable/ideal one? I'm not sure if it's
> worth 'fixing' it in the kernel.

What does sk2 represent here? I don't think that the sk2 should
be preferable. For now, it is selected by the creating order, and
there should not be a case that relies on the socket creation
order......would it?

So the socket should be selected by priority, and sk1, which is binded
on eth0, has higher priority, which is awarded by the users.

I noticed that the net-next is open, so we can use Kuniyuki's
solution instead, which is better for the performance ;)

Thanks!
Menglong Dong