netdev - Re: Question on DSA switches, IGMP forwarding and switchdev

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]

Date:   Sat, 20 Jun 2020 20:01:38 +0200
From:   Daniel Mack <daniel@...que.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Jason Cobham <jcobham@...stertangent.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Ido Schimmel <idosch@...sch.org>,
        Jiri Pirko <jiri@...nulli.us>,
        Ivan Vecera <ivecera@...hat.com>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: Question on DSA switches, IGMP forwarding and switchdev

On 6/20/20 4:35 PM, Andrew Lunn wrote:
>> So yes, we can read the code here, but I'm wondering which packet types
>> would then get this flag set, and which won't. Because in case of
>> IGMP/MLD, the packets are in fact forwarded, but the meaning of the flag
>> in skb is to prevent the skb from being forwarded further, which seems
>> wrong in all cases.
>>
>> I'm thinking maybe the flag should never be set?
> 
> It is a while since i did much with multicast, so please correct me
> when i'm wrong...
> 
> IGMP can use different group addresses as far as i remember.
> Join/leave uses the group address of interest. But query can use
> 224.0.0.1 or the group address.
> 
> The bridge should learn from joins, either spontaneous or as a reply
> to a query. When it sees a join, it should add a multicast FDB to the
> hardware for the group, so traffic is forwarded out that port.

Yes, except it's the MDB in this case. But the bridge must also forward
the IGMP queries and reports to other ports, otherwise a cascaded
multicast router won't see the membership reports and hence won't send
frames to our switch.

> So for real multicast traffic, we do want the flag set, the hardware
> should be doing the forwarding. If we don't set the flag, we end up
> with duplication when the SW bridge also forwards the multicast
> traffic.

Yes, agreed.

> For IGMP/MLD itself, we probably need to see what the switch does. For
> IGMP using the group address, does the multicast FDB rule match and
> cause the hardware to forward the IGMP?

No, because snooping is enabled on all ports of the switch by the
driver, all IGMP frames are redirected to the CPU port and not egressed
on any other port, regardless of the entries in the ATU.

> If yes, then we need the flag
> set, otherwise the IGMP gets duplicated. If no, then we don't want the
> flag set, and leave the SW bridge to do the forwarding, 

Exactly.

> or reply
> itself if it is the querier.

If it has memberships itself.

> 6352 uses the EDSA tagger. But the same bits exist in the DSA tag,
> which the 6390 uses, due to incompatibility reasons. So it would be
> nice to extend both taggers.

But the tag format seems to be a bit different on EDSA from what you
described in your other mail. In my datasheet, the code bits are spread
across octet 2 and 3.

I'll send a patch for EDSA that works for me and solves the problem I
had, and then leave it to someone with access to the datasheets of
variants implementing the DSA tagging to replicate and test that.


Thanks for your help!
Daniel