netdev - Re: [BUG] net/ipv4: inconsistent routing 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: <55C4D803.3090108@redhat.com>
Date:	Fri, 07 Aug 2015 09:08:35 -0700
From:	Alexander Duyck <alexander.h.duyck@...hat.com>
To:	Zang MingJie <zealot0630@...il.com>
CC:	Alexander Duyck <alexander.duyck@...il.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Stephen Hemminger <stephen@...workplumber.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [BUG] net/ipv4: inconsistent routing table

On 08/07/2015 01:23 AM, Zang MingJie wrote:
> IMO, the routing decision is determined, given a specific routing
> table and local network the result MUST be determined, independence of
> how/what order the routing entry is added.
>
> Now there are two ways to configure the system resulting EXACTLY the
> same routing table and local addresses, but the routing decision is
> totally different.
>
> SAME routing table, DIFFERENT routing decision, there MUST be bugs in kernel

I wasn't arguing that the behavior is undesirable, but the likelihood of 
having a default route assigned to a local address should be pretty 
low.  If the system is the default route of others then it should have a 
different default gateway than itself.  For example an office router 
would end up pointing to the ISP as the gateway, and the ISP would 
either point to some other provider or run a BGP configuration.  So in 
the case of the default route transitioning to us we should end up 
having to delete and update the default route anyway.  This is likely 
one of the reasons why there hasn't been any issues reported with this 
behavior until now.

I'm just wondering if the work involved to fix it is going to be worth 
it.  We have to keep in mind that this will result in a change of 
behavior for existing users and we don't know if anyone might be 
expecting this type of behavior.

We basically are looking at one of three options.  The first one is to 
just delete the route if you add the gateway as a local address or 
remove it.  That would be consistent with what you might see if the 
address was the sole address on an interface of its own.  The second 
option is to update the nh_scope which I believe should be transitioned 
between RT_SCOPE_HOST to RT_SCOPE_LINK if I am understanding things 
correctly.  The third option is we don't change the behavior and just 
document it.  This would then require manually deleting and restoring 
any routes that use a recently modified address as their gateway.

Based on your feedback I'm assuming you would probably prefer the second 
option.  I'm just waiting to see if there are any other opinions on the 
matter before I act.

Thanks.

- Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html