netdev - Re: [PATCH v2 rfc 0/8] IGMP snooping for local 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <9ECEF4E4-A39B-4578-8BDC-7842D20F3C81@gmail.com>
Date:   Wed, 06 Sep 2017 09:06:23 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Roopa Prabhu <roopa@...ulusnetworks.com>,
        Andrew Lunn <andrew@...n.ch>
CC:     netdev <netdev@...r.kernel.org>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Woojung.Huh@...rochip.com, jbe@...gutronix.de,
        sean.wang@...iatek.com, john@...ozen.org
Subject: Re: [PATCH v2 rfc 0/8] IGMP snooping for local traffic

On September 6, 2017 8:54:33 AM PDT, Roopa Prabhu <roopa@...ulusnetworks.com> wrote:
>On Tue, Sep 5, 2017 at 5:47 PM, Andrew Lunn <andrew@...n.ch> wrote:
>>> The third and last issue will be explained in a followup email.
>>
>> Hi DSA hackers
>>
>> So there is the third issue. It affects just DSA, but it possible
>> affects all DSA drivers.
>>
>> This patchset broken broadcast with the Marvell drivers. It could
>> break broadcast on others drivers as well.
>>
>> What i found is that the Marvell chips don't flood broadcast frames
>> between bridged ports. What appears to happen is there is a fdb miss,
>> so it gets forwarded to the CPU port for the host to deal with. The
>> software bridge when floods it out all ports of the bridge.
>>
>> But the set offload_fwd_mark patch changes this. The software bridge
>> now assumes the hardware has already flooded broadcast out all ports
>> of the switch as needed. So it does not do any flooding itself. As a
>> result, on Marvell devices, broadcast packets don't get flooded at
>> all.
>>
>> The issue can be fixed. I just need to add an mdb entry for the
>> broadcast address to each port of the bridge in the switch, and the
>> CPU port.  But i don't know at what level to do this.
>>
>> Should this be done at the DSA level, or at the driver level?  Do any
>> chips do broadcast flooding in hardware already? Hence they currently
>> see broadcast duplication? If i add a broadcast mdb at the DSA level,
>> and the chip is already hard wired to flooding broadcast, is it going
>> to double flood?
>>
>
>On the switch asics we work with, the driver has information if the
>packet was
>forwarded in hardware. This is per packet reason code telling why the
>CPU is seeing the packet.
>The driver can use this information to reset skb->offload_fwd_mark to
>allow software forward.

I am not positive this is universally available across different switch vendors. In Broadcom tag (net/dsa/tag_brcm.c) the reason code definitely tells you that but it also largely depends on whether you have configured SW managed forwarding or not and that translates in having either the HW do all the address learning itself or having SW do it which is less desirable since you end-up with a possibility huge FDB of 4k entries to manage in SW.


-- 
Florian