netdev - Re: [PATCH] net: VRF: Fix receiving multicast traffic

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: <1bb15beb-fbab-c365-2519-11cf9d13007c@cumulusnetworks.com>
Date:   Fri, 23 Sep 2016 07:49:34 -0600
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Mark Tomlinson <Mark.Tomlinson@...iedtelesis.co.nz>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: VRF: Fix receiving multicast traffic

On 9/22/16 9:06 PM, Mark Tomlinson wrote:
> 
> On 09/23/2016 10:41 AM, David Ahern wrote:
>> On 9/22/16 4:10 PM, Mark Tomlinson wrote:
>>> On 09/23/2016 03:14 AM, David Ahern wrote:
>>>> l3mdev devices do not support IPv4 multicast so checking mcast against that device should not be working at all. For that reason I was fine with the change in the previous patch. ie., you want the real ingress device there not the vrf device.
>>>>
>>>> What test are you running that says your previous patch broke something?
>>> Although we do not expect any multicast routing to work in an l3mdev,
>>> (IGMP snooping or PIM), we still want to have multicast packets
>>> delivered for protocols such as RIP. This was working before my previous
>>> patch, but these multicast packets are now dropped. This current patch
>>> fixes that again, hopefully still with the benefits of my first patch.
>>>
>> can you discern which check is making that happen?
>>
>> It does not make sense to look at the in_device of a vrf device for mcast addresses. For IPv6 linklocal and mcast is specifically blocked. IPv4 should do the same. So, how is RIP getting the packet at all?
> This might be due to some other changes we've made for VRF and multicast 
> but haven't sent upstream. In particular, a change to do_ip_setsockopt() 
> and its handling of IP_MULTICAST_IF as well as IP_ADD/DROP_MEMBERSHIP. I 
> am guessing that without these changes, we wouldn't be able to receive 
> multicast packets in RIP. With our changes, the in_dev->mc_list does 
> contain the RIP MC address (224.0.0.9) in the master interface, and so 
> the function ip_check_mc_rcu() returns success with the master only.
> 
> Our RIP daemon is VRF-aware. So it does use setsockopt(SO_BINDTODEVICE, 
> "vrf-master") when running in a VRF. Without following it all the way 
> down, I believe that it is this that allows the multicast lookup at the 
> top of ip_check_mc_rcu() to succeed on the vrf-master, but not the 
> ingress interface. That is, in_dev->mc_list does contain 224.0.0.9 only 
> on the vrf-master. Provided the lookup in ip_check_mc_rcu() succeeds (im 
> != NULL), this function can return success.
> 
> Are you interested in the other patches at the moment?
> 

Yes, but with the context of the bigger IPv4 multicast solution. I am on PTO today - about to get on a plane. How about we leave the upstream kernel as is - i.e., drop this patch. You can carry it locally with the others. We can take a look at the bigger mcast picture for 4.10. Agree?