netdev - Re: [PATCH net-next] net: restore DSA behavior of not overriding ndo_get_phys_port

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]

Message-ID: <20200722224654.nqlw4nhdm22f7a5d@skbuf>
Date:   Thu, 23 Jul 2020 01:46:54 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org,
        andrew@...n.ch, vivien.didelot@...il.com, jiri@...lanox.com,
        edumazet@...gle.com, ap420073@...il.com, xiyou.wangcong@...il.com,
        maximmi@...lanox.com, mkubecek@...e.cz, richardcochran@...il.com
Subject: Re: [PATCH net-next] net: restore DSA behavior of not overriding
 ndo_get_phys_port_name if present

On Wed, Jul 22, 2020 at 03:11:09PM -0700, Florian Fainelli wrote:
> On 7/22/20 3:06 PM, Vladimir Oltean wrote:
> > On Wed, Jul 22, 2020 at 02:53:28PM -0700, Florian Fainelli wrote:
> >> On 7/22/20 1:53 PM, Vladimir Oltean wrote:
> >>> Prior to the commit below, dsa_master_ndo_setup() used to avoid
> >>> overriding .ndo_get_phys_port_name() unless the callback was empty.
> >>>
> >>> https://elixir.bootlin.com/linux/v5.7.7/source/net/dsa/master.c#L269
> >>>
> >>> Now, it overrides it unconditionally.
> >>>
> >>> This matters for boards where DSA switches are hanging off of other DSA
> >>> switches, or switchdev interfaces.
> >>> Say a user has these udev rules for the top-level switch:
> >>>
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p0", NAME="swp0"
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p1", NAME="swp1"
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p2", NAME="swp2"
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p3", NAME="swp3"
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p4", NAME="swp4"
> >>> ACTION=="add", SUBSYSTEM=="net", KERNELS=="0000:00:00.5", DRIVERS=="mscc_felix", ATTR{phys_port_name}=="p5", NAME="swp5"
> >>>
> >>> If the DSA switches below start randomly overriding
> >>> ndo_get_phys_port_name with their own CPU port, bad things can happen.
> >>> Not only may the CPU port number be not unique among different
> >>> downstream DSA switches, but one of the upstream switchdev interfaces
> >>> may also happen to have a port with the same number. So, we may even end
> >>> up in a situation where all interfaces of the top-level switch end up
> >>> having a phys_port_name attribute of "p0". Clearly not ok if the purpose
> >>> of the udev rules is to assign unique names.
> >>>
> >>> Fix this by restoring the old behavior, which did not overlay this
> >>> operation on top of the DSA master logic, if there was one in place
> >>> already.
> >>>
> >>> Fixes: 3369afba1e46 ("net: Call into DSA netdevice_ops wrappers")
> >>> Signed-off-by: Vladimir Oltean <olteanv@...il.com>
> >>> ---
> >>> This is brain-dead, please consider killing this and retrieving the CPU
> >>> port number from "devlink port"...
> >>
> >> That is fair enough. Do you want to submit such a change while you are
> >> at it?
> >>
> > 
> > If I'm getting you right, you mean I should be dropping this patch, and
> > send another one that deletes dsa_ndo_get_phys_port_name()?
> > I would expect that to be so - the problem is the fact that we're
> > retrieving the number of the CPU port through an ndo of the master
> > interface, it's not something we can fix by just calling into devlink
> > from kernel side. The user has to call into devlink.
> 
> Yes, that is what I meant, that an user should call the appropriate
> devlink command to obtain the port number, this particular change has
> caused more harm than good, and the justification for doing it in the
> first place was weak to begin with.
> -- 
> Florian

If the patch at this link is considered appropriate:
https://patchwork.ozlabs.org/project/netdev/patch/20200722224312.2719813-1-olteanv@gmail.com/
then this can be considered superseded by that.

If not, please apply this.

Thanks,
-Vladimir