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:   Sun, 11 Oct 2020 18:30:55 +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 Sun, Oct 11, 2020 at 02:29:08PM +0200, Kurt Kanzenbach wrote:
> On Tue Oct 06 2020, Vladimir Oltean wrote:
> > It would be interesting to see if you could simply turn off VLAN
> > awareness in standalone mode, and still use unique pvids per port.
>
> That doesn't work, just tested. When VLAN awareness is disabled,
> everything is switched regardless of VLAN tags and table.

That's strange, do you happen to know where things are going wrong?
I would expect:
- port VLAN awareness is disabled, so any packet is classified to the
  port-based VLAN
- the port-based VLAN is a private VLAN whose membership includes only
  that port, plus the CPU port
- the switch does not forward packets towards a port that is not member
  of the packets' classified VLAN
When VLAN awareness is disabled, are you able to cause packet drops by
deleting the pvid of the ingress port? Therefore, can you confirm that
lan1 is not a member of lan0's pvid, but the switch still forwards the
packets to it?

> Therefore, the implementation could look like this:
>
>  * bridge without filtering:
>    * vlan_awareness=0
>    * drop private vlans
>  * bridge with vlan filtering:
>    * vlan_awareness=1
>    * drop private vlans
>  * standalone:
>    * vlan_awareness=1
>    * use private vlans
>    * forbid other users to use private vlans to allow
>      configure_vlans_while_not_filtering behavior in .vlan_prepare()
>    * forbid use of lan0.<X> and lan1.<X> in .port_prechangeupper()
>
> So, this should work, or?

Yes, this is an alternative that could work.