netdev - Re: [PATCH net] net: br: Fix igmp snooping offload with CONFIG_BRIDGE_VLAN

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 4 Oct 2017 13:52:20 +0900
From:   Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
To:     Ido Schimmel <idosch@...sch.org>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Andrew Lunn <andrew@...n.ch>
Cc:     Toshiaki Makita <toshiaki.makita1@...il.com>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net] net: br: Fix igmp snooping offload with
 CONFIG_BRIDGE_VLAN_FILTERING

On 2017/10/04 1:42, Ido Schimmel wrote:
> On Tue, Oct 03, 2017 at 12:25:08PM -0400, Vivien Didelot wrote:
>> Andrew Lunn <andrew@...n.ch> writes:
>>
>>>> The vlan will be effective only when vlan_filtering is enabled.
>>>> When vlan_filtering is disabled, vlan information is still kept in the
>>>> bridge and gets effective later when vlan_filtering becomes enable.
>>>
>>> O.K, so things are starting to get clearer.
>>>
>>> So when vlan filtering is disabled, the hardware should just ignore
>>> the requests to add the vlan to the hardware?
>>>
>>> When vlan_filtering is enabled, are all the vlans in the software
>>> bridge again offloaded? Or do we need to remember all the vlans which
>>> we ignored while vlan filtering was disabled? The average switch has
>>> nowhere to store these disabled vlans. It can only store active vlans.

Seems that __br_vlan_filter_toggle() only propagates
SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING.
IMHO vlan-related objects (vlan, fdb, and mdb) should be remembered if
vlan_filtering can be enabled later. But this sounds redundant as the
same information is maintained in the bridge so I'm not sure this is the
best way.

>>
>> When vlan_filtering is enabled on the bridge, the bridge code does
>> propagates the default_pvid again if I recall correctly.

I couldn't find it in the source...

>>
>> In my opinion the hardware mustn't ignore the VLAN requests, because we
>> seem to agree that vlan_filtering disabled means that the target ports
>> should not care yet about 802.1Q. So having some unused hardware VLAN
>> entries and some ports with disabled 802.1Q mode must work together.

Probably I don't fully understand you, but I think hardware can ignore
VLAN requests while vlan_filtering is disabled, as long as they are
properly populated to hardware on enabling vlan_filtering.

>>
>> That being said we still have the wrong hardware FDB populated when
>> CONFIG_BRIDGE_VLAN_FILTERING is enabled but not vlan_filtering...
> 
> The driver can make sure it's able to handle the configured
> `vlan_filtering` state during port enslavement to the bridge and also
> forbid it from being toggled once it's enslaved.

That is a simple solution.
One concern is backward compatibility. I wonder if we can prohibit
toggling for some driver which currently allows it.

-- 
Toshiaki Makita