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:   Thu, 29 Oct 2020 01:05:31 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Kurt Kanzenbach <kurt@...utronix.de>,
        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,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net-next v7 2/8] net: dsa: Give drivers the chance to
 veto certain upper devices

On Wed, Oct 28, 2020 at 12:43:44PM +0200, Vladimir Oltean wrote:
> On Wed, Oct 28, 2020 at 08:42:15AM +0100, Kurt Kanzenbach wrote:
> > From: Vladimir Oltean <vladimir.oltean@....com>
> > 
> > Some switches rely on unique pvids to ensure port separation in
> > standalone mode, because they don't have a port forwarding matrix
> > configurable in hardware. So, setups like a group of 2 uppers with the
> > same VLAN, swp0.100 and swp1.100, will cause traffic tagged with VLAN
> > 100 to be autonomously forwarded between these switch ports, in spite
> > of there being no bridge between swp0 and swp1.
> > 
> > These drivers need to prevent this from happening. They need to have
> > VLAN filtering enabled in standalone mode (so they'll drop frames tagged
> > with unknown VLANs) and they can only accept an 8021q upper on a port as
> > long as it isn't installed on any other port too. So give them the
> > chance to veto bad user requests.
> > 
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> > Signed-off-by: Kurt Kanzenbach <kurt@...utronix.de>
> > ---
> 
> In case reviewers have doubts about this new DSA operation in general.
> I would expect that when LAG support is merged, some drivers will
> support it, but not any tx_type, but e.g. just NETDEV_LAG_TX_TYPE_HASH.
> So it would also be helpful in that case, so they could veto other types
> of bond interfaces cleanly. So I do see the need for a generic
> "prechangeupper" operation given to drivers.

There is always the interesting question, do we want to veto, or
simply not accelerate it? We will want to consider that case by case.

       Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ