netdev - Re: [RFC] bhash2 and WARN_ON() for inconsistent sk saddr.

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: <187eec2c-f7d5-7c5a-1c75-aae9f7c98998@linux.dev>
Date:   Thu, 3 Nov 2022 21:58:48 -0700
From:   Martin KaFai Lau <martin.lau@...ux.dev>
To:     Kuniyuki Iwashima <kuniyu@...zon.com>, joannelkoong@...il.com
Cc:     davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        kuni1840@...il.com, martin.lau@...nel.org,
        mathew.j.martineau@...ux.intel.com, netdev@...r.kernel.org,
        pabeni@...hat.com
Subject: Re: [RFC] bhash2 and WARN_ON() for inconsistent sk saddr.

On 11/2/22 11:35 AM, Kuniyuki Iwashima wrote:
>> For avoiding adding sockets with ADDR_ANY to the bhash2 hashtable, I
>> think the issue is that other sockets need to detect whether there's a
>> bind conflict against an ADDR_ANY socket on that port, so if ADDR_ANY
>> is not hashed to bhash2, then on binds, we would have to iterate
>> through the regular bhash table to check against ADDR_ANY, where the
>> bhash table could be very long if there are many sockets bound to that
>> port.
> 
> Right, inet_bhash2_addr_any_conflict() will not work then and it means
> we cannot enjoy the very merit of bhash2.

One thought is to have the ADDR_ANY sk linked at either end of the bhash (head 
or tail) so that it can get to the ADDRY_ANY sk faster in bhash when checking 
conflict.  However, only the 'struct hlist_node owner' alone may not be good 
enough.  Just an idea.