netdev - Re: Commit 0ddcf43d5d4a causes the local table to conflict with the main table

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: <vQHKO4hEjMsPEg58jVn-H9jQMjxIANbP2DLKgZBdlkgqJHd6p_rMnz-o5QhonUL8cJG_AwXhVwse0e5941mXjN-9LCbtdSVGDYK4OEv3hhM=@protonmail.com>
Date:   Tue, 29 Oct 2019 07:07:21 +0000
From:   Ttttabcd <ttttabcd@...tonmail.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     "davem@...emloft.net" <davem@...emloft.net>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        Netdev <netdev@...r.kernel.org>,
        "lartc@...r.kernel.org" <lartc@...r.kernel.org>
Subject: Re: Commit 0ddcf43d5d4a causes the local table to conflict with the main table

> I am dropping all of the above. The fact is commit 0ddcf43d5d4a
> ("ipv4: FIB Local/MAIN table collapse") has been in the kernel for
> over 4 and a half years so hopefully by now most of the network
> developers are aware that the tables are merged, and become unmerged
> when custom rules are added.

First of all, we can't assume that all developers already know this, even if this feature has been added to the kernel for more than 4 years, because this does not appear in the "ip route" or "ip rule" man page.

> I would argue that adding routes to the local table is a very "geek"
> thing to do. Normally people aren't going to be adding routes there in
> the first place. Normally routes are added to main as the assumption
> is you are attempting to route traffic out to some external entity.
> The local table normally only consists of the localhost route and a
> set of /32 addresses as I mentioned earlier.

You are right, most people in the world will not do this, I am doing this to test the local route in the transparent proxy.

> I would disagree. There is a significant performance gain to be had
> from this commit. What it is basically doing is taking advantage of
> the fact that normally your local trie is going to consist of /32
> routes and localhost. In the vast majority of cases there will never
> be a clash as you have pointed out.

> If anything what I would suggest, assuming the priority inversion
> issue you have pointed out needs to be addressed, would be to look at
> adding a special case for the addition of non /32 non-localhost routes
> to local so that we could unmerge the table on such an addition. The
> instance of non-/32 routes being added to local has apparently been
> low enough that this hasn't been an issue up until now, and if we are
> wanting to focus on the correctness of the fib lookup then this would
> be the easiest way to sort it out while maintaining both the
> performance and correctness.

If you have done experiments that can bring a lot of performance improvements, then please keep the function of merging the main and local tables.

However, please add an explanation of this merge in the man pages of "ip route" and "ip rule", and explain that the route table will be re-segmented after adding the policy route.

As you have described, re-segmenting the local route table when a route other than /32 is added to the local route table is also a very good solution. This fully complies with the priority of the local table and the main table.