netdev - Re: [PATCH v2 net-next] net: ipv6: put host and anycast routes on device with address

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]

Date:   Mon, 21 Aug 2017 07:19:29 -0600
From:   David Ahern <dsahern@...il.com>
To:     Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:     netdev@...r.kernel.org, yoshfuji@...ux-ipv6.org,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH v2 net-next] net: ipv6: put host and anycast routes on
 device with address

On 8/18/17 6:28 PM, Hannes Frederic Sowa wrote:
> David Ahern <dsahern@...il.com> writes:
> 
>> On 8/18/17 6:05 PM, David Ahern wrote:
>>> On 8/18/17 5:15 PM, Hannes Frederic Sowa wrote:
>>>> Hello David,
>>>>
>>>> David Ahern <dsahern@...il.com> writes:
>>>>
>>>>> @@ -2688,15 +2716,9 @@ struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev,
>>>>>  {
>>>>>  	u32 tb_id;
>>>>>  	struct net *net = dev_net(idev->dev);
>>>>> -	struct net_device *dev = net->loopback_dev;
>>>>> +	struct net_device *dev = idev->dev;
>>>>>  	struct rt6_info *rt;
>>>>>  
>>>>> -	/* use L3 Master device as loopback for host routes if device
>>>>> -	 * is enslaved and address is not link local or multicast
>>>>> -	 */
>>>>> -	if (!rt6_need_strict(addr))
>>>>> -		dev = l3mdev_master_dev_rcu(idev->dev) ? : dev;
>>>>> -
>>>>>  	rt = ip6_dst_alloc(net, dev, DST_NOCOUNT);
>>>>>  	if (!rt)
>>>>>  		return ERR_PTR(-ENOMEM);
>>>>
>>>> I am afraid this change might break Java:
>>>>
>>>> <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/unix/native/libnet/net_util_md.c#l574>
>>>>
>>>> I am all in for this change, but maybe it might be necessary to mask
>>>> RTF_LOCAL routes with "lo" somehow.
>>>
>>> That's asinine. The if_inet6 processing is just getting the 'lo'
>>> interface index. Why scan the file looking for that? The ipv6_route
>>> processing is assembling routes against the loopback device regardless
>>> of what the route is. Do you know why - what the route list is used for?
>>
>>
>> If I read it correctly, seems to be a 2.4 workaround:
>> - only user of the route list is needsLoopbackRoute()
>> - only caller of needsLoopbackRoute is here:
>>
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/65464a307408/src/java.base/unix/native/libnet/net_util_md.c#l828
> 
> I agree that it looks like dead code now. But I know for sure that this
> code has been excercised at least at some point in time and caused
> problems for JVMs on Linux with IPv6.
> 
> On the top of this file I found this comment:
> 
> -- >8 --
> /* following code creates a list of addresses from the kernel
>  * routing table that are routed via the loopback address.
>  * We check all destination addresses against this table
>  * and override the scope_id field to use the relevant value for "lo"
>  * in order to work-around the Linux bug that prevents packets destined
>  * for certain local addresses from being sent via a physical interface.
>  */
> -- 8< --
> 
> I don't know if it makes sense to dive down into java history (and I
> also found e.g. net-snmp scanning /proc/net/ipv6_route). The same
> problem might be visible via RTM_GETROUTE dumps if applications
> implement their own source address selection maybe. :/

Dave: The java code appears to be dead code from 2.4 time frame. no
longer relevant for this patch.

Hannes: I believe the net-snmp use case is populating the MIB. MIB
entries, like the proc files and rtnetlink responses, will have the
change in that host routes show the device with the address rather than
loopback. But, looking at the send code I don't see this change having
an impact.