netdev - Re: [PATCH net-next v6 2/7] net: dsa: Add DSA driver for Hirschmann Hellcreek switches

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]

Date:   Tue, 6 Oct 2020 16:42:47 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Kurt Kanzenbach <kurt@...utronix.de>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Richard Cochran <richardcochran@...il.com>,
        Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
        ilias.apalodimas@...aro.org
Subject: Re: [PATCH net-next v6 2/7] net: dsa: Add DSA driver for Hirschmann
 Hellcreek switches

On Tue, Oct 06, 2020 at 03:23:36PM +0200, Kurt Kanzenbach wrote:
> On Tue Oct 06 2020, Vladimir Oltean wrote:
> Does this mean that tagged traffic is forwarded no matter what?

Precisely. The bridge VLAN table should be irrelevant to the acceptance
or forwarding decision of the packet if vlan_filtering is 0.

> That doesn't work with the current implementation, because the VLAN
> tags are interpreted by default. There's a global flag to put the
> switch in VLAN unaware mode. But it's global and not per bridge or
> port.

Oh, there is? Maybe you can use it then.

JUST FOR CONTEXT, for sja1105 and felix/ocelot, this is the mode that
they're operating in, when a bridge with vlan_filtering=0 is configured
as an upper.

In sja1105, I don't even have the VLAN awareness flag that you have. So
I need to change the VLAN TPID from 0x8100 to 0xdadb, and the switch
will think that VLAN-tagged frames aren't VLAN. So all frames are tagged
internally by the switch with the port-based VLAN ID and PCP, when in
vlan_filtering=0.
And because my knob is global and not per bridge either, I just set
ds->vlan_filtering_is_global = true and let DSA handle the rest.

As for ocelot/felix, those switches have 2 knobs:
- VLAN awareness: does the ingress port derive the classified VLAN from
  the packet's 802.1Q header? If yes, the VLAN ID and PCP are taken from
  the packet. If not, they are taken from the port-based default.
- VLAN ingress filtering: does the ingress port drop a VLAN-tagged frame
  if the classified VLAN is not installed in its ingress filter?

As you may guess, even for ocelot/felix, when we have a bridge with
vlan_filtering=0, we are still configuring it as:
VLAN awareness = disabled
VLAN ingress filtering = enabled

Because the classified VLAN is not derived from the packet, it will
always be equal to the pvid of the port, which is installed privately by
the driver. So no packet drops due to VLAN, regardless of VLAN ID.

> So you're saying private VLANs can be used but the user or the other
> kernel modules shouldn't be allowed to use them to simplify the
> implementation?  Makes sense to me.

Yes.
And because the user is more likely to install VLAN 2 and 3 than 4095
and 4094, maybe you could use private VLANs from the end of the range,
just to make this restriction less obvious (or maybe not at all).

> The egress port has to member to that VLAN.

Same as ocelot/felix. This is the reason why we make it VLAN-unaware.
There's no point in disabling just VLAN ingress filtering if the end
result is still going to be a drop, albeit due to a different reason (no
destinations).