netdev - Re: [PATCH] ip: find correct route for socket which is not bound to a device

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: <55FF65CB.1020205@oracle.com>
Date:	Mon, 21 Sep 2015 10:04:59 +0800
From:	Wengang Wang <wen.gang.wang@...cle.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] ip: find correct route for socket which is not bound to a
 device

Hi David,

Thanks for your review on this.

在 2015年09月18日 12:20, David Miller 写道:
> From: Wengang Wang <wen.gang.wang@...cle.com>
> Date: Wed, 16 Sep 2015 14:34:15 +0800
>
>> For multi-cast, we should find valid route(thus get the meaniful pmtu) for
>> the package on the socket which is not bound to a device(sk_bound_dev_if
>> being 0) too.
> Your patch breaks exactly the situation explained in full detail
> in the huge comment about the first change you are making:
>
> 			/* Special hack: user can direct multicasts
> 			   and limited broadcast via necessary interface
> 			   without fiddling with IP_MULTICAST_IF or IP_PKTINFO.
> 			   This hack is not just for fun, it allows
> 			   vic,vat and friends to work.
> 			   They bind socket to loopback, set ttl to zero
> 			   and expect that it will work.
> 			   From the viewpoint of routing cache they are broken,
> 			   because we are not allowed to build multicast path
> 			   with loopback source addr (look, routing cache
> 			   cannot know, that ttl is zero, so that packet
> 			   will not leave this host and route is valid).
> 			   Luckily, this hack is good workaround.
> 			 */
>
> That situation will now fail after your patch.

Yes, I noticed the above comment before I made the patch. I have 
question regarding that
comment: Seems it's talking about the loopback source address(loopback 
device interface
is with the index of 1). Do you think we can make something specific to 
loopback device and
let the package with other outbound devices go through the routing cache?


> So I cannot apply this patch, sorry.
>
> I know what you want, you want to end up with a cached route that
> will track the PMTU.
Yes, that's exactly what I want.
Actually the user space can work fine by adding a syscall 
setsockopt(..., SO_BINDTODEVICE, ..) to
bind socket to the device. Well, the problem here is that there are a 
lot of user space applications which
don't bind sockets and they are working fine with old kernel(2.6.39). 
When moving to new kernel(4.x),
the problem appeared. And seems it's hard for force all of them change 
to bind sockets and recompile.
  -- that's the pain.  Do you have any idea which won't break the 
existing hack but can help with my case?

thanks,
wengang
--
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