netdev - Re: [PATCH net-next 1/4] ipv6: Calculate hash thresholds for IPv6 nexthops

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] [day] [month] [year] [list]

Message-ID: <c5123836-d40b-45cb-b5fb-84ba397f90a5@gmail.com>
Date:   Thu, 3 May 2018 19:13:36 -0600
From:   David Ahern <dsahern@...il.com>
To:     Thomas Winter <Thomas.Winter@...iedtelesis.co.nz>,
        Ido Schimmel <idosch@...sch.org>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        Ido Schimmel <idosch@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
        "nikolay@...ulusnetworks.com" <nikolay@...ulusnetworks.com>,
        "pch@...bogen.com" <pch@...bogen.com>,
        "jkbs@...hat.com" <jkbs@...hat.com>,
        "yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
        "mlxsw@...lanox.com" <mlxsw@...lanox.com>
Subject: Re: [PATCH net-next 1/4] ipv6: Calculate hash thresholds for IPv6
 nexthops

On 5/2/18 2:56 PM, David Ahern wrote:
> On 5/2/18 2:48 PM, Thomas Winter wrote:
>> Should I look at reworking this? It would be great to have these ECMP routes for other purposes.
> 
> Looking at my IPv6 bug list this change is on it -- allowing ECMP routes
> to have a device only hop.
> 
> Let me take a look at it at the same time as a few other bugs.
> 

I see the problem: the multipath code for IPv6 tries to helpful and
auto-determine that a new route can be appended to an existing one --
basically adding another nexthop if it already exists. What it should be
doing is requiring the NLM_F_APPEND to modify an existing route. If the
same prefix and metric comes down and APPEND or REPLACE is not set it
should fail EEXISTS rather than consolidating into an ECMP.

Fixing it to do the right thing will break existing userspace, but as it
stands it prevents dev only nexthops (no gateway) and replace with a
REJECT route ends up adding another route

e.g., ip -6 ro replace unreachable 2001:db8:104::/64

leaves the existing route and adds a new entry which can never be hit:

$ ip -6 ro ls
...
2001:db8:104::/64 via 2001:db8:101::2 dev veth1 metric 1024 pref medium
unreachable 2001:db8:104::/64 dev lo metric 1024 pref medium
...